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ABSTRACT 


This thesis develops a complete set of protocols, which utilize a block 
cipher, e.g., the NBS data encryption standard, for protecting interactive 
user-computer communication over physically unsecured channels. The use of. 
the block cipher protects against disclosure of message contents to an. 
intruder, and the protocols provide for the detection of message stream 
modification and denial of message service by an intruder. The protocols 
include facilities for key distribution, two-way login authentication, 
resynchronization following channel disruption, and expedition of high 
priority messages. The eueet® esters eeeinee oe meevsee to sane vei the 
protocols, Poth in a terminal and in a host: soups erica ic bps acl Atscusses “ae 


results of a test taplemedtation of the modules on Multics. 
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Chapter One 


Introduction 


This thesis develops protocols to organize the gee of ikryption to oxi 
with the problem of providing a secure’ communication path between a user at a 
terminal and hig compugation in a remote host computer system. This problem 
is of major concern as. more and more cotaputing ie performed interactively via 
unsecured communication facilities and thevalue and’ tmportance of the data so 
accessed increases. Secure communication fs no Longer ‘a Concern just for the 
military. . With the introduction of a standard’ encryption’ algorithm [NBS] that 
can. be implemented on a: single » integrated ciréuit chip; and with the’ 
decreasing costs of hardware.components, it te new-practical to consider ‘using 
encryptionrbased, measures to protect data enroute from auser terminal to a 
remote host facility. 

_, Assuming the existence of.an intruder, armed. with a large scale computer 
positioned in. the connection between. a user terminal end a remote host — 
computer, a number of different types: of threats may be posed. » The intruder 
may, net. only passively copy each meseage transmitted in either direction on 
the conmmection, but he may actively disrupt the flow of messages on the 
connection, . modifying,. delaying, reordering,’ and. rerotting © tiessages or 
synthesizing, new messages and inserting them. into the coaneétion. As the 
communication path is assumed to be physicelly:unsecured, there fs no way that 


an. intruder can be.prevented: from engaging: in such acts, but the protection 
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measures developed in the thesis do prevent disclosure of message contents, 
provide detection of message stream modification, and provide suteedion of 
denial of message service. 

The use of encryption protects against. disclosure of the contents of the 
messages Heth transmitted on the connection. It also. serves to bind together 
the user level data and a tag that identifies messages, so that an intruder 
cannot, with a high . probability, modify.user level data without detectably 
modifying the ae. The use of such a tag in all messages: provides’ a basis for 
establishing the authenticity of each message:received: on the commas tion: The 
design of the tag prevents any undetected reordering, deletion, ‘fF rerouting 
of unmodified messages on the connection. It also provides for the highly 
probable detection of apwrious or modified messages introduced into ' the 
connection. Protocols are provided, employing special control messages, to 
distribute encryption keys on the connection, detect intruder attacks 
involving delay or destruction of message traffic, and resynchronize both ends 
of the connection in the event of disruption. A protocol also is employed for 
the secure handling of high priority messages on the connection. | 

The thesis presents a design for: the protection modules needed at both 
ends of the connection to implement: the protocols. At the terminal end,’ the © 
protection module is simple enough for it to: be construeted using a general 
purpose microprocessor and a. special purpose: chip for. enciphering and” 
deciphering operations. At the host end, the the .proteétion module is 
constructed in software within the host. computer.: The only spéctal hardware 
Support assumed for the host module is a machine instruction for performing 


enciphering and deciphering of message blocks, perhaps using the same chip. 
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The preferred positioning of the protection modules relative to the various 
hardware and software facilities typical of existing computer communication 
system is discussed. 

In order to test the completeness of the protection measures designed in 
this thesis and evaluate their impact on the human interface of a computer 
utility, a test implementation was carried out on the Multics [MIT] system. 
Experience with this test implementation indicates that the modules do detect 
intruder acts resulting in message stream modification or denial of message 
service and mitigate the impact of connection disruption on the interface 
presented to the user. The performance degradation resulting from use of the 
modules, assuming hardware support for the encryption/decryption algorithm, 


should be negligible for most users. 
Related Work 


As this thesis is not primarily concerned with cryptographic systems, the 
work of such people as Kahn [KD1, KD2] and Shannon [Sha] is only indirectly 
peleeed. It may be the case that work similar in nature to that reported on 
in this thesis has been carried out by researchers within the Department of 
Defense, but because such work would be classified I am not aware of it. 

In the open literature a number of papers have dealt with the use of 
encryption for protection of data communicated via physically unsecured 
channels [Bar, Sav, ScP, Tur]. In particular the work of Paul Baran at Rand 
[Bar] stands out as an example of a major, systematic study of the problems 
involved in securing military data communication networks. This study, like 


others in the area, takes the view of providing secure communication 
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facilities for a variety of purposes other than nee: coumundoarton with 
computation in remote host eoapukeran It stad iscee enphasis on protecting 
the communication has from the threat of traffic snalysie, ‘unlike this 
thesis, and thus assumes the existence bf relatively secure ia caraea inte nodes 


in the commun ication “network to provide “Link encryption of messages, in 


addition to end-to-end encryption. A fundamental difference between york of 


ae ae: 


this sort and the thesis is that the “fotees treates hie propies as one of 


Des 


secur ing commun ication facilities, rather than as a one wy providing a secure 
virtual connection between a user and his s computation executing ina remote 


host computer. 


Several papers were generated at IBM in the early ‘seventics, py Horst 
Feistel et al. [{FH1, FH2, FNS, Smi, SNO], dealtag with che: developaeie of the 
Lucifer encryption algorithm and its application to remote terminal .to. host. 


communication systems and to remotely accessed patabates: p eere Esper 


ac.ae day 


discussed the design of Tacifer ‘and presented a | simple protocol for use over 


Sed go 


hal f-duplex channels. That “work is much closer to ais body of this cheats, 


than the works noted abuve: dn terms of at “intended “application, “However, 
the pkotocots daserihed tri the. TBM papers are ‘suited only for use in 


half-duplex éGamuniewtton enviroments ‘end do not creat gi of ee protection 


ye beo8 
or 2 


problems, CBs ‘adtouatre detection by the host of connection blocking by an 

intruder and secure traneatanton of high priority meswages, that arian ae 
the encryption protection mechanisms are used for general purpose interactive 
computing, as opposed to database accessing. Re pai Pe the = coupling of: the 
eheryption protection wieasures with database “accessing. s seems to violate 


concepts of procedural tapering of system fiiekions. This violation seems “to 
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be a result of trying to use the encryption prefectton: mechanisms fo. overcome 


deficiencies in the internal proteceton mechanisns of the shost Sompucer used 


ade 


as these experiments. 
More recently, Dennis Branstad, of the National Bureau of Standards, nae 
proposed some protocols for use in authentication, host access control, and 


distribution of working keys in. a necere ony tromeene . (Bral, Bra2]. 


whtae 


Branstad’ » woEk does not develop protocols to deal with problems such as 


we ae 


message sequencing, automatic renyurbrgatea tions and bigh _ priority meatene 


pracewelite: The feocacola Proposed by Branstad are described in terms of a 
parereatar network: enviroment that does’ ‘not Saccore? simple dialup lines of 


the type ised to access many interactive host computers today. The protocols 


gs OM vos. es 


described in this thesis can be used in either a general network or. simple 
dialup enviroment. Fur ther suggestions for protocols to organize the’ use of 


“the National Bureau of Standards fata encryption standard are. B expected fe ips 


forthcoming amend ‘oion mee cand from other researchers. 


Oughine of Thesis 


Chapter two peateure the mode? of the ‘terminal-host connection that is 
aad in the thesis, and develops the protection goals chat characterize the 


security ‘that can be provided for a | physically, unsecured beast rie ha 


bet Gey 


chapter tied presente characteristics of cryptographic a7erons that make _ thea 
suitable for protecting shrenective (aear-computer comm tet toe and selects 


the NBS “data encryerson standard as the basis for _ implementation of the 


ae eee 


pforeceion protocols. 
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Chapter three develops an authentication echeme: for nessages rea a 
‘full-duplex Somnus ication saviroment: The ihaorer. éle deals with ‘protocols 
for the distribution of ye in support of the authentication mechanism, and 
presents a protocol for the secure initialization of the chandel at login 
a. 7 or Lt fos 3 Ot 

Chapter four develops proteetton measures for detection 0: of denial ve 


service, when effected by blocking of message traffic on the connection: The 


ne Bie re 


RB! 


chapter also discusses “protocols that | are used to restore synchrony of the 
message counters used for authentication on the éhannatc | - : 
Chapter five discusses high priority messages, ©.8.» ' "attention" eignale. 
An extension to the connection model. ‘develloced| in chapter two d ie s presented ‘to 
‘ gupport “high” ‘priority messages transmitted Hoa ‘the terminal to ‘the host. A 


move fe 


protocol is introduced for handling “auch “messages eth ie. she | protection 


‘ 
aha 
oo 


framework provided eae Gomaunication, 

Chapter six iivestigares the fantove hak Bb cin ai of 
the encryption protection modules in the communication path between a aser’s 
terminal and his computation. The primary factors that Ant kueece this 
‘positioning are security and functionality constraints. “Differences ee Best 
communication system architectures that are ralevadt to protection module 
positioning, especially with respect to support of high priority moneeges and 
character echoing, are exaninad = 

Chapter seven presents a detailed discussion of the control structure of 
both the terminal and host dipeaeelon ‘nodules. “The eauies are characterized 


in terms of finite state machines driven by inputs from the iher Cermindl che 


user’s process, the ciphertext connection and timeouts at the host module. 
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Chapter eight discusses the test implementation of the proposed protocols 
undertaken on the Multics aystem. Some of the design. issues associated with 
actually incorporating a host protection module in a production Multics system 
are considered. A discussion of the dmpect of the protection protocols upon 
the perro mace oF the user-host connection and the host overhead to support 
the protection protocols is pEseantes 

Chapter wine reviews the voncluslons sl the thesis and proposes topics 
“bot further study, AtncLuding construct ion of production terminal and host 
‘protection modules; further perfomance evaluation, and generation of 
‘encryption keys. 7 | | io . . . . | 
| The appendix eiecusses: the , susceptability of the lucifer and NBS ciphers 
ee: a particular form of cryptanalysis, exbaustive ey searching with matching 
intercepted ‘cleartext and ciphertext. Recent research _(DH1] indicates that 


this form of cryptanalysis ay be a practical means of attacking the NBS 


ciphak;, but that the Lucifer cipher is eeeret ane to Buch an attack. 


Chapter Two 


Protection Goals and Encryption 


In order to discuss the protection problens associated with physically 
unsecured communication channels, this chapter presents a ‘model of a 
terminal-host connection, complete with ‘intruder, and examinee specific 
examples of intruder threats. From ‘this model , che sua ticabie protection 
goals for such a connection are established. Next, saceyet ton 4a introduced 
as a basis for meeting these goals. The thesis auee not involve the details 
of cryptographic systems or cryptanalysis. Rather, cryptographic systene are 
viewed as "black boxes” that exhibit certain haawlens germane to providing a 
secure communication path between a user and a remote nose “computer. The 
chapter concludes by discussing the peopar ties: chee” “ake a cryptographic 
system suitable for this application and that influence the Sebee s ay ake 
high-level synchronization and authentication peticdis developed in laced 


chapters. 
The Terminal-Host Connection Model 


For generality, we consider a full-duplex connection between a user 
terminal and a computer utility. Such a connection has the property that 
messages may be transmitted in both directions simultaneously. We can further 
simplify this description by modeling the full-duplex connection as a pair of 
independent simplex channels, each capable of transmitting messages in one 


direction only.. At, this time we shall ignore the physical details of the 
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connection. Thus, such equipment as line adaptors, modems, front end 
processors and possible intermediate switching nodes will not be considered 
here, but will be discussed in enapEee six. na tnens. we shall identify only 


three parte of the connection, as being “of. interest at ‘this time: the terminal 
é a ads % a 
terminal, the host, and an intruder. 


‘ 


Both the terminal and the Rowe are presumed | ‘to reside in secure areas. 


The terminal. may “be used at aifterent tines by various users with different 
~Tape i ge 

pavubity requirements Gad different authorization levels. “the 1 host may, also 

provide services to a “aiveres user community, not all of whom will eaploy the 


tam 


protection measures dencribed in this thesis. 


4 


"The int radar “IT be mepeesented by a "Large computer, under hostile 
control, situated in the Sounection between the. terminal cand the hoe. aul 


meeeenc® Creneettcad in either direction on ne connection must pone through 


*the™ “intruder. The ‘intruder can perform any Processing he ‘deattea. on the 
Peay = c Bg bse * 
message s-- copying ‘them, delaying, then, absorbing “thea, modifying chen, 


oe bas 


synthesizing new messages or allowing them to pass ‘transparently. Figure, cy 


dees vibes this ‘configuration < 


Figure 2-1 


General Model of a Full-Duplex Connection with Intruder 
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Protection Goals 


We would = to transmit messages in both directions in a way that nas 
the presence of the intruder: irrelevant to the security of the connection. 
However , as the model suggests, with a physically unsecure connection the 
intruder could shed: some or all message traffic in his computer. Ina less 
drastic RCEZORS the intruder could delay all maneace traffic in either or both 
directions. Acts of this nature can be termed "denial of meesase service" 
‘threats. In our eodei with ali messages on the cofnection passing through 
the intruder’s computer, it is not poastpie to prevent denial of message 
abrwice and we shall not address the more generat problem of countering ‘such 
threats. - 

Similarly, as our model suggests, it is not possible to prevent ene 
modification of a message transmitted over the connection or Ene: ideeodazt ton 
of a spurious message. Included in the set of Gab ious messages are aot only 
bit strings constructed by the intruder, bik ‘also messages piavioaaly 
intercepted ae intruder. Acts such as these can be deaiganred as “message 


stream modification" threats. (1) 


(1) One may also term acts of this nature "active" wiretapping threats, in 
contrast to "passive" wiretapping threats that involve no intervention in the 
transmission of message traffic but merely involve. listening in on the 
conversation. 
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With these limitations in mind, we can establish three goals for 


He stds Bie 


protection measures applied to a physically unsecured connection: 


1. Prevention of release of message contents 
2. Detection of moaeage stream modatication 


3. Detection of denial of message. jee 


We will now examine various intruder threats to determine what form of 
protection measures’ are required to achieve thee goals. (2) © 

Encryption techniques have been used primarily ag countermeasures to 
eiuvaate of message contents disclosure ‘{Kp2]. By enciphering messages 
transmitted between the terminal and the host, this first goal can be achieved 
within the limitations of the encipher ing scheme used and subject to security 
violations external to ae meet vere the Loss of the key by the user. The 
Sactphering is controlled by a key held by both hater and the host, and the 
ability to decipher a message is based exetusively on possession of the key. 
Moat PYANg our earlier terminal—host connection model to include an encryption 


protection module (EPM) at Fhe terminal oo and suitable encryption act 


at the host end results in the cog€iguration shown in Figure 2-2. The 


5 ate 


protocols used to establish an enciph _ communication path between the 


hig 
4 


(2) A form of intruder threat that does not fall within these three categories 
is referred to as traffic analysis. This passive threat involves analysis of 
patterns of message traffic, or examination of address headers in multiplexed 
channels, without actually reading the contents of the ‘multiplexed — channels, 
in an effort to determine the nature of the conversation taking place. 
Countermeasures against traffic analysis ‘threats ” “Ubually ‘tavolve the 
generation of "dummy" messages at each end of the connection in order to 
maintain a constant rate of message traffic® and link-to-lihtk ‘encryption of 
messages to prevent an intruder from reading message headers. Although the 
protocols developed in the thesis will support ‘such additional 
countermeasures, threats of this type will not be treated. 
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terminal and the host computer, by exchanging messages enciphered with the 


same key, are discussed in chapter three. 


Terminal . Intruder 


Cie ese 


Figure 2-2 


Connection Model with Encryption Protection. Modules 


In order to achieve the second goal noted. above, ‘detection of message 
stream modification, some mechanism must be employed that permits a message to 
be verified as authentic. In thie context authenticity iaplies age only thet 
the message received was: sent by the aches end 6f the connection, but farther 
that the message is the next one in the emquence of mcesaxee ~cuerently being 
transmitted. By associating with each medecge 0 tag chet te chen enc iphered 
along with the message, the problem of message authentication ean be attacked. 
Chapter three proposes a scheme for ‘tneutng wadmaaen: chat is the besia® of a 
simple authentication technique for use in a fil duplex. Coestnicerion 
environment. | 

In order to achieve the third goal, detection of denial of eee 


service, request-response protocols will be introduced to permit automatic, 


eee ee 


time~controlled monitoring. of the inteactey of the connection by the host. 
These protocols will be developed in chapter four. oe 

The protection measures used in this thesis to ‘eewiave all three goals 
are based on encryption. As well as masking the user-level data from _ the 


intruder, encryption _indivisibly binds the data to the control information 
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required to achieve the other two goals. We now shall examine some properties 
of cryptographic systems to determine which systems” are suitable for this 
application and to develop an understanding of the nature of the security 


provided by encryption. 


Terminology 


A cipher is an algorithmic transformation performed $a a symbol-by~symbol 
basis on any data Although there are technical Haviee ea between : the 
terms encipherment and encryption [KD2, Sha], the two terms will be Sead 
interchangeably throughout this thesis to refer to the application of a cipher 
_to data. An encryption algorithm is any algorithm that implements a cipher. 
The input to an encryption algorithm is referred to as cleartext vnile the 
output from the algorithm is designated as ‘ciphertext. The transformation 
performed on the cleartext to encipher it is controlled by a key. To be of 
use in a communications context, there must also exist a matching decryption 
algorithm that reverses the encryption transformation when presented with the 


same key. Figure 2-3 shows the general form of such a. cryptographic system. 


KEY KEY. 
cleartext 


re: 


ENCRYPTION | ciphertext DECRYPTION 
ALGORITHM |-~--~-—---~->] ALGORITHM  [- 


Figure 2-3 
"Black Box" Model of a Cryptographic System 


cleartext 


wewneere ea 2> 
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Two major classes of encryption techniques that have been used in modern, 
non-voice telecommunications and digital computer applications are stream and 
block encryption. The former method per forms bit-by-bit transformations on 
the cleartext under the control of a stream of key bits, usually using some 
easily reversible operation, e.g., addition modulo 2. The latter method 
enciphers ficed-eead blocks of bits under the control of a key that is 
frequently the same size as, or somewhat larger than, the blocks being 


encrypted. 


Stream Ciphers 


Stream ciphers have an advantage that they ‘can- operate on a stream of 
eke text in real time, enc ipher ing each bit as it is generated by combining 
it with a bit from a key stream. A stream cipher in which the key stream 
consists of random bits as long as the combined length of all messages that 
‘are ever to be transmitted using this stream, a Vernam cipher, constitutes an 
unbreakable cipher [KD1, KD2, Sha} . ‘In practice, the volume of communication 
traffic and the logistic difficulties associated with providing each user with 
a sufficient quantity of keys cause most stream ciphers to utilize 
pseudo-random bit streams, based on a fixed-length key, that have very long 
periods. a i 

Various techniques may be used in stream ciphers to generate the key 
stream. The source of these bits may be completely independent of the 
cleartext stream, e.g., a pseudo-random number generator primed with a small 
initial key or a tape that ia.-¢6 be used only once. With such an independent 


key stream, changes to individual bits in the ciphertext do not propagate to 
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other portions of the ciphertext stream. This is an advantage in that 
transmission errors that alter the values of bits of the ciphertext do not 
affect the ability of the receiver to correctly decipher subse quent 
transmissions. (3) This characteristic is a disadvantage in eousevaseine 
message stream control protocols because it fails to bind together user-level 
data and control information. 

Stream ciphers can also be constructed in which the key stream is a 
function of the cleartext or ciphertext and uses some initial, "priming" key 
{Sha]. Ciphers employing this approach achieve interbit dependence that can 
be used to detect errors in transmitted ciphertext, as such errors interfere 
with the correct decipherment of subsequent transmissions. Transmitted 
ciphertext can also be used as input to key stream generation in 
self-synchronizing ciphers that achieve interbit se pendance but resume correct 
operation following transmission errors, after some fixed number of unaffected 
bits are received [Sav]. Even with the use of self-synchronizing stream 
ciphers, an error in the received ciphertext may result in damage to multiple 


messages, 


Block Ciphers 


In contrast to stream ciphers, block ciphers transform entire blocks of 
bits under the control of a key. If the block size is n bits, then the size 
of the cleartext space (the range of cleartext block values) and the size of 


the ciphertext space (the range of ciphertext block values) is a 


(3) Undetected insertion or removal of bits from the ciphertext stream results 
in a loss of deciphering ability in ciphers of this sort. 
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A block cipher maps the space of cleartext blocks fae eae space of 
ciphertext blocks. In order that the deciphering of a block yield an 
unambiguous cleartext block the mappings must be reversible, hence one-to-one 
and, in this case, onto, because the sizes of the spaces are equal. Thus, we 
can view a block cipher under the control of a single key as defining a 
permutation on the set of n-bit blocks. There are (2%)! distinct permutations 
on the set of n-bit blocks. In practice it is not feasible to implement a 
block cipher that realizes all of the possible permutations because of the 
size of the key required and the Vopical complexity of the cipher. In che 
block ciphers we shall discuss, only e aeati fraction of the permutations, 
e.g., on the order of the ee of the text spaces, is used. | 

For all values of n,. the block size, a block cipher is equivalent to the 
classical "simple substitution" cipher, and when n is 7 or 8 the block 
corresponds to a single character from some small alphabet and_ this 
equivalence becomes very apparent. This syatem is known to be very weak, not 
because of the structure of the system, but becaune:.of the small size of the 
blocks usually used. The cipher is subject to analysis of chase eaianey 
distribution of individual blocks, for comparison with the known frequency 
aisteipacion, of characters in large samples of cleartext. By increasing the 
size of the block so that n is on the order of 50 or 100, and by constructing 
the cipher so that the frequency characteristics of the Nea penents ot the 
block are concealed, such frequency distribution analysis pacoues infeasible 
because the bie of the effective aiphabet haa been increased to 290 1 


and the resulting cryptographic system is very good. 
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‘The Lucifer aie developed at IBM is an example ofa block cipher 
scheme using 128-bit bloc ke and equal size keys (FHI, FR, FNS, smi, SNO] : 
Each bit of ciphertext in a block getierated ‘by the Lucifer algorithm is a 
function of each bit of the ‘key and each ‘pit ‘of ‘the ‘cleartext block. 
difference of only one bit in either the key or the cleartext results in 
ciphertext in which each bit is changed with approximately ‘equal | probability? 
Conversely, a change in one bit of @tther the key or “the ciphertext will 
result in changes in an average. of: 50% ‘of ‘the bits of the | dec iphered 
. cleartext. 

‘Because of thiis sensitivity of the bkock to modification, the inclusion 
of a k bit error detection (or identification)’ field in “a cleartext ‘block 
provides a basis for detecting moltfication of the block with a probability of 
undetected error of 1/(24), this ineanws that’‘any error in ‘a block propagates 
within the block to such an’ extent that tte détection can “be made extremely 
likely, yet subsequent blocks are unaffected bythe error. Feistel claims 
that because this ‘interbit dependence within a block is functionally 
not-linear, it is difficult to use the depetidence as an’ aid in dec tpher ing the 
blocks [FNS]. 

For block ciphers, synctirony: of the two ends of the commumication channel 
_-is.required only to the extent that each must load’‘the’ same key and the blocks 
must be correctly delimited. Higher-level message stream synchronization, 
e.g., correct ordering of blocks, cag be accomplished by. ‘protocols that use 
sequence numbers soapaumstsi within the Blocks. “‘Meoynchtontzation at that level, 
we will denonstrate in chaptét four, is posstbie ‘a thoue transmitting special. 


epee 


unenc ‘pheved messages. . 
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An encryption algorithm used for securing a user/.compyuter communication 
channel , must conceal the contents of transmissions and provide a basis. for 
effectively implementing various authentication and symchronization protocols. 
While both stream and block ciphers can conceal . effectively, black ciphers 
seem to provide a simpler to use basis for the protocols. In order to detect 
various intruder threats, the protocols associate with each message certain 
information that identifies the message as genuine. The encryption algorithm 
must bind together the user’s messages.and the protocol. information .so. that 
any attempt to tamper with the. message will be reflected in: the protocol: 
information. In the event of intrusion or error, the, protocols should. . allow 
re-establishing higher-level message stream syachromy without going outside of: 
the .encryption scheme. These combined eis cenaheenooans to indicate that a 
block cipher similar to JLucifer. would provide a natural. basis for : the 
devel opment of the protection protocols, . since it. provides sybsetantial . 
interbit dependence in each block while. limiting _the.. impact, of errors to. 
single, well-defined blocks. (4) 

A block encryption, algorithm has been proposed as a Federal Information 
Processing. Standard (FIPS). by the National Daren ei <Stendexaa: (ural; Bs). 


This algorithm operates on 64-bit blocks, uses a 64-bit key . (5) and employs. 


(4). fhis. should not be.-construed as. an i adearipns: that... stream. ciphers, 
especially auto-synchronizing ones, cannot be used as the foundation for 
protocols similar to the ones presented in this thesis, (,Rather,. block ciphers. 
such as Lucifer appear to form a more natural basis for fixed-length mennsee 
protocols of the type presented in this thesis. aye tos 


(5) Although a 64-bit key is used with the NBS sigor ieee only 56 bits of this 
key are actively used in the encryption algorithm and NBS has recommended that 
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many of the same design principles used in the 128-bit Lucifer. If this 
algorithm is adopted as a FIPS, it will probably become a de facto industry 
standard as well. Already software is being offered that performs the 
encryption as specified by this algorithm [Bri], and hardware implementations 
of the algorithm using a single large-scale integrated chip are being planned. 
Thus, the protection protocols and mechanisms developed in this thesis will be 
examined in the context of probable use of this encryption algorithm, although 
the protocols are not restricted to the particular block or key size 
associated with the NBS proposed standard. 

Although this cipher appears resistant to cryptanalysis, recent work by 
Diffie and Hellman [DH1] indicates that automated, exhaustive searching of the 
key space is not unreasonable for an analyst provided with adequate resources 
and small amounts of intercepted ciphertext and partial matching cleartext. 
This thesis is not concerned with the topic of cryptanalysis and assumes that 
the cipher scheme used as the foundation for the protection protocols is 
resistant to cryptanalytic attacks. In order to better understand the nature 
of the wealmess noted by Diffie and Hellman, the appendix contains a brief 
discussion of exhaustive searching of the key space in the case of the Lucifer 
and NBS ciphers. In chapter three we shall note, in some instances, how this 


characteristic of the NBS cipher might affect the protection protocols. 


Summary 


This chapter presented a model of a physically unsecured terminal-host 


connection and established goals for the protection that we shall attempt to 


the remaining eight bits act as parity bits to be utilized for error detection 
in key generation, distribution and storage [NBS]. 
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provide through the use of encryption and the peokoedls developed in later 
chapters. We have examined some properties of cryptographic evateha and have 
chosen a particular block cipher as the basis for the development of 
protection protocols. | This type of cipher is well suited to the application 
because of the high degree of interbit dependence it provided for each block 
and because “of the independence of each block with eeatee to propagation of 
errors. | | 
A specific example of this type of cipher has been proposed as a Federal 
Information Processing Standard and, if adapted: will provide a broad basis 
for exchange of encrypted information. Thus, we will adopt it as the basic 
Sipeencaniad system upon which further protection mechanisms will be 
constructed. However, the protocols presented in ind higate can be used with 


other block encryption schemes that provide suitable cryptographic protection. 


Chapter Three 
Message Stream Authentication 


Having chesen, in chapter two, Lucifer-style block ciphers as the basis 
for implementing protection protocols, this chapter presents a simple scheme 
for authenticating messages that uses the properties of *such ciphers. This 
authentication scheme achieves the goal of detection of message stream 
modification through independent messagé sé quencé numbering ® on each channel. 
This chapter aleo presents a protocol. for chaiging keys that supports the 
message authentication scheme and that serves asa babies for a time-dependent, 
two-way authentication login protocol’. ‘The message’ authentication acheme 
further serves as the fomdation for protocols that detect denial of service 
and. that resynchronize the connection following disruption of cotimunication. 
These last two. protocols are presented in chapter four. 

Message Modification Threats and Authentication 

Part of the protocol information enciphered ae part of each message to 

verify its guchenticrty is a tag. (1) Although there are a variety of forms 


that this authenticator tag may assume, (2) we are interested only’ in designs 


(1) Although a logical unit of: correspondente may be so large as to require 
several encrypted message blocks for its transmission, for simplicity the term 
"message" will refer to the logical contents of oné‘btock.” 


(2) For example, verification of a message may be based not-on the knowledge 
of the exact bit pattern contained in the tag, but rather on the tag 
satisfying some computational of structural éornstraints,eig., it may always 
contain twice as many "OQ" bits as "1" bite or it may be a cyclic redundancy 
check of the rest of the block contents. 
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that. require the tag to consist of a bit pattern that must precisely match a 
pattern held by the receiver of the message. When used in a block enciphered 
with a Lucifer-type algoritha, such tags..are optimal with respect to 
utilization of block space in that a k bit tag conveys precisely k bits of 
authentication information and can be forged by an iatruder with probability 
of 1/(2*), | 

It can be argued that such a tag is not necessary to the authentication 
process, especially when an encryption scheme with high degree of interbit 
dependence is being employed, since a.spuriows message would: not decipher. into 
meaningful cleartext. While this argument has some .merit. when considering. 
messages received by the user at his terminal, it does not seem that most: 
software systems exhibit a corresponding ability to make intelligent 
judgements as to the meaningfulness of messages. Moreover, messages directed 
to the user may admit to a wide range of "meaningful" contents when they 
represent answers to a virgin problem or consist of random cumbexa: Thus, we 
insist that authentication be based on the use of- some form of message 
tagging. 

To prevent an intruder from modifying a message ayd not the tag 
assoctated with it, it is necessary that the tag be attached to the message in 
such a manner that modification of any part of the encrypted block is very 
likely to result in modification of the message age the use of a block 
cipher system of the type discussed in chapter two, and placement of the tag 
in the measage block achieve this Widbicad ceqult at ucenige Gag and message 


interdependence. 
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We shall distinguish two classes of message stream modification attacks: 
attacks that involve modification of genuine message blocks or synthesis of 
new blocks, and attacks that tuveive modification of the message stream 
through manipulation of genuine, intact blocks. Attacks of the first type can 
be detected because of the interdependence of the authenticator tag and the 
remainder of the block as noted above. In the latter category are acts such 
as deletion of blocks, insertion of copies of old blocks, and rerouting of 
blocks back to their sender. We will now discuss the design of an 
authenticator tag that permits detection of such attacks. 

To detect these message stream modification attacks, we propose that each 
tag consist of a non-cycling bit pattern that is predictably recognizable by 
the receiver, logically chaining each message to its transmitted predecessor, 
and a bit identifying the origin of the message, the terminal or the host. We 
also require that if messages are removed or destroyed, examination of the tag 
on successfully received messages can be used to determine the number of 
messages so lost, for purposes of user notification, auditing, and possible 
higher level retransmission. Thus, this predictable sequence of patterns used 
in the tags must be capable of being mapped analytically tits a strictly 
monotonic sequence that is dense in the integers. (3) Using this scheme, the 
receiver of a message is expecting a particular tag and 2 other tag will 


result in rejection of the message as spurious. Tags of this sort can be used 


(3) Here we mean "analytically" in the sense that a receiver of messages 
should be able to compute the value of the tag that will appear in the ith 
message in the sequence using only his knowledge of the tagging scheme and the 
value of the first tag. i 
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to perform the eau of message aichentieation iy conjunction with message 
sequencing and origin identification. | | | 

In the original Lucifer implementation, deoigned fat use on half-duplex 
connections, Feistel proposed the use of message aut near icneten tags (FHI, 
FNS]. The tag consists of bits from fixed eee in the last comiaEtext 
block received, or from the last block eranaeteted if this is the first 
message in an incoming group, and thus was predictable by the receiver 
Because half~duplex connections do not allow simultaneous transmission in both 
directions, this scheme can use this simple fore of peeenee chain “os to 
authenticate message traffic in both directions, Since the tag bits used for 
chained authentication are a function of the contents of each oe message 
block, Feistel has argued that there is little chance of “repetition, anew 
there is no guarantee of this. Moreover, there is no apparent means for 4 a 
receiver to ascertain the number of messages lost, should a message arrive out 
ere | _ 

In light of the requirements set forth above for a tag design that 
enforces strict weseaee rea quenciae and lost message accountability, it appears 
that consecutive numbering of est cant starting from zero, tranamitted on 
each of the channels provides the gaia acceptable form of tag se quenc ing. 
(4) In order to fulfill the requirement of tag uniqueness (non=cycling tag 
sequence), the tag must be large soscah 46 not "wrap around" during the 


lifetime of the key. 


(4) The inclusion of the counter assures that each ciphertext block is 
different, even if the same text is transmitted multiple times. In situations 


“where the, blocks are used to transmit individual charactera, this tag design 


prevents:the cipher from becoming a weak substitution cipher on single 
characters. 
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Each end of the connection maintains two coum rerey one, eeferring to the 
number of meonagen travenitted by that’ ‘ent of the. ecthectton’ ‘and the other 
keeping track of the. number of messages received, ~ aah paneadeaton counter 
for a channel is used as the source of the owen’ number poreton of the tag 
for messages tranemitted on that channel. (3) Thesé doiitters’ reyee Rovek cycle 
during the lifetime of the key and efforts should be made to insure that 
different connections have little chance of using the same key. 

This tag design provides Be de cactiss of pits cee ae to modify message 
traffic through rerouting, reetder ing: or deletion of genirine messages ori this 
connection. The design provides probabilistic detection of any attempt by an 
intruder to either synthesize a message block with ai acceptable tag or to 
modify the contents of a’genuine meisage biakk withdut “affecting” the tag. 
Using the Lueffer or WBS © algorittim, the probability “of érroneous 
authentication of a wées#age modified in’ thi® fashion {8"io greater than 1/(2*) 
if a k bit tag is ‘employed. (6) Figure’ 3-1<dllusttates this type éf tab 
architecture, (The type “field indicated’ is used “te “distinguish “control 


m@éssages associated with the protection protocols developed tater.) 


te 


yh Les ot 


(5). This counter strangéwert may .alac-bé°viewed “dé ‘associating’ two counters 
with each channel, recording the number of messages transmitted and received 
on that channel. This use of counters corresponds to the concept of 
eventcous ts as described by Reed. and Kanodia. in [RK]... 0 ew eee 


(6) If there is: any predictability to the contents of the tessages, “the 
probability of erroneous authentication “by the “user - “ts even lower as ‘the 
intruder: “Cannot syatenatical Ly force “ale ari intg ful be “der level ‘Wessage | ‘contents - 
either.’ oR Pore in : 


t Ages 
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origin | transmission | message . 
bit counter type 


authenticator tag 


message specific 
data 


Figure 3-1 


Generic Format of Message Blocks 


A characteristic of both this tag scheme and the original Lucifer 
authentication technique is that they provide an intruder with the cleartext 
of a portion of each measage block: the tag. We alluded to the nature of the 
problem in chapter two and the appendix provides a more. detailed discussion of 
the subject. From the key. searching discussion in the appendix, it is 


apparent that this knowledge alone is adequate for an intruder to determine 


the key that is being used by attempting to decipher several intercepted: 


blocks under a single key and checking for. a match.on the:tag field of all of 


the blocks. In the case. of relatively gmall..key spaces, like the -NBS. 


algorithm’s 56-bit effective key, this may constitute a significant threat to 
the security of the system. 
Although attempts could be made to overcome this problem in the tag 


scheme imposed above by concealing the tag, this is probably not worthwhile. 


(7) In fact, interactive user-computer dialoge tend te.contain many messages - 


(7) The tag could be enciphered under a separate key using a block size equal 
to the tag size and .then inserted in the meaaage black.and enciphered along 
with the message data... If the tag bite.were the only -portion. of -the. block 
known to the intruder, this would substantially increase the work involved to 
break the key. 
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that are very predictable by a sophisticated intruder, e.g., stylized login 
and error response messages from the host. Because these messages contain 
adequate amounts of known information for an intruder to use in a key space 
search it appears that efforts to conceal the tag portion of a message for 
this reason are not fruitful. Rather, a cipher should be used for which 


exhaustive key searching is an impractical cryptanalytic technique. 
Key Distribution Protocols 


Because the tag value described above must never cycle, the tag must be 
large enough to uniquely identify the maximum number of messages that are to 
be transmitted over either of the channels during the lifetime of the key. 
Rather than having the size of the tag determined by the expected maximum 
message traffic volume on one of the channels over some extended time 
interval, e.g., a month, a year or the lifetime of the host system, it seems 
appropriate that the primary factors in determining the size of the tag should 
be the probabilistic degree of protection desired for the channel and the 
portion of the block capacity devoted to the tag. This motivates the concept 
of changing keys as a means of controlling the size of a tag. 

If keys are randomly generated bit strings, then messages enciphered 
under one key effectively represent random bit strings when deciphered under a 
different key. Thus, messages enciphered under the control of a key different 
from the one currently in use on a connection pose no more of a_ threat than 
messages synthesized by an intruder using randomly generated bits. Moreover, 
if there is no easy wy to use knowledge of a previous key to discover a_ key 


currently in use, or vice versa, the changing of keys establishes a "firewall" 
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around the data transmitted under each separate “— Thus, there is 
additional impetus to limit the lifetime of a key in order to minimize the 
volume of message traffic that would be compromised in the event a key is 
discovered. | 

If the key lifetime extends over more than deogin session, then it is 
also necessary to be able to restore the counters ad by both ‘ite terminal 
and the host so that the message tagging can resume from the. point where it. 
was terminated. (8) It is undesirable to require both ends of the connection 
to retain the values of the Gola tate Febd he last login session for each user 
or to. have the host retain these values aud tranemit thea to the terminal in 
cleartext as part of an initialization procedure. These “approaches are 
undesirable primarily because interactive sessions do not always terminate in 
an orderly fashion, due to cdamimicarion peut saene or nose failures: Even 
when sessions do terminate in an orderly fashion, a eysten crash at the host 
could result in the loss of the counter varies and thus prevent or compromise 
sub se quent “Logins. Thus, it would be eepectally convenient if a key lifetime 
were no longer than one interactive gasaiGas so that the problem of assigning 
the correct values to _ the message Bees eéald be eliminated. If a 
different key were used for each login sere 4 then the ee counters 
could be set to zero at the beginning of each basetons | | | 

Unfortunately, despite the savenkaged noted above, there are logistical 


difficulties associated with frequent key changes. A new key must be 


(8) If the counter values are not restored properly at the beginning of each 
terminal session, but rather set to some fixed initial value or some value 
that may already have been used in previous message exchanges, then messages 
recorded from earlier sessions could be inserted into the connection by an 
intruder and would be erroneously authenticated by the protection modules. 
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distributed to the user via some secure channel, e.g., registered mail or 
bonded courier. One convenient medium that hag been proposed | far. user . key 
record ing de magnetic stripped plastic cards [Sud]. Chang ing keys by isauing 
new cards or recalling and chang ing old cards entails subatantial time and 

practical. This points 
to the need for transmitting a new key over veer ne connection. The 
new key would have to be enciphered using some key already held by both ends 
of the connection. There are two basic approaches that may be used to 
transmit ane keys: chained key changes and two-level key distribution 
spateue: 

With the chained key approach, a new key is enciphered under the last key 
that was issued and replaces that old key for all communication until another 
key change occurs. This forms a chain of key changes and, if an intruder 
discovers one key in the chain, he can easily decipher all messages 
subsequently transmitted as he can follow the chain of key changes. (9) 

Using this chained key technique, if this new key were recorded in place 
of the old one on the magnetic stripped card, then a loss of this new key by 
the host in a crash would preclude further enciphered communication until a 
new key could be issued via some channel ‘external to the system. . The 
likelihood of key loss by the host ia enhanced by the fact that the key held 


by it is changing frequently, so that backup media may not have— the most 


(9) Given the exhaustive hey searching rechn i ques’ from the | appendix, it is 
also possible for an intrudér to work backwards through the key. ‘changes, using | 
the identity of the discovered key as known data enciphered™ uider the previous 
key, to disctosa the contents of all ititercepted int étactive sessions. This 
possibility is not a new vulnerability since during any key lifetime there 
will be enough information available to an inttyder in the form of predictable 
message authentitators to break each key by exhaustive search. anyway. 
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recent copy. Also, the recording of a new key on the user card at the 
terminal requires the introduction of équipment capable of reading and writing 
on the magnetic stripped cards, increasing the cost and complexity of the 
bdewina modules and making them more prone’to failure. 

Using a two-level key distribution system, each new key is transmitted 
enciphered under a distinguished key used only for issuing new keys, thus 
preventing an intruder from working forward through the key changes. (10) 
Some protocol must be established to allow both ends of the connection to know 
when to use the distinguished key to decipher a new key. duiu pectocol aay be 
implicit, e.g., by issuing a new key only at the beginning of an interactive 
.gession, or it may require transmitting a message, sacdohered under the key 
currently in use, indicating that the next Getedge will be. a new key 
enciphered under the distinguished key. x 

In order to avoid the difficulties associated with a simple, hashed: hey: 
change protocol, a two-level key distribution systen will be ceed: atthe 


beginning of each login session, and a chained key “change approach will be 


(10) Here, too, an intruder using exhaustive searching could work backwards 
through the protocol used to issue new keys, after discovering one key, and 
discover the distinguished key. If he could discover this distinguished key, 
an intruder could then easily decipher each key,change and disclose the 
contents of all conversations, or impersonate the user in future interactions. 
The basic protection against this threat must come from a key space large 
enough to . preclude exhaustive searching. When too “small a key space is the 
problem, as is the case with the NBS cipher,. SORS: mpapurs: .O£ extra, protection 
for the distinguished key, can. be obtained | by usdng. a special protocol for. 
initial key loading. ‘Single blocks with no. autk ation; igformation can be 
used to tranemit a series of intermediate Jeys. each.enciphered. under the 
previous key. This protocol increases the . work, requixed, to. discover the 
distinguished key linearly with the number. of. int intermediate. keys... Yet it is 
used only at the beginning of the session, 99. that the. impact .on . channel. 
utilization is minimal. 
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used during the session. (11) The distinguished key held by the user and the 
system on a long term basis will be designated as the primary key. It will be 
used only to issue a new secondary key at the beginning of each login session. 
The secondary key will be used for the encryption of regular message traffic. 
A secondary key also can be transmitted under the control of a previously 
transmitted secondary key, thus allowing use of multiple, chained secondary 
keys during a single interactive session. | 

The primary key for a user will be recorded on his magnetic stripped card 
and will be retained by the host in much the same way a password is retained 
by many aystedus The protocol for changing from the primary key to a 
secondary key, and for later secondary-to-secondary chained key changes, 
requires the host to transmit the secondary key in a pair of enciphered 
messages, each containing half of the new key. (12) After the terminal 
receives a secondary key, it changes to the new key, resets the message 
counters, and sends a message to the host confirming receipt of the new key. 
The host has changed over to the new key and reset its counters after sending 
the new key messages, so it is ready. to receive this confirmatory response. 

The key change messages hee the same general format as other messages, 
including an authenticator tag. In the case of a chained change from one 
secondary key to another, the tag need not be based on current counter values, 


but can be a static, known value, e.g., "0", as such key changes occur only 


(11) An example of the use of both types of key change protocols in the same 
system is provided by the protocols used with the IBM 3612 consumer 
transaction facility [IBM2]. 


(12) If the key is approximately the same size as a message block, as is the 
case for Lucifer and the NBS cipher, then the key will not fit in one block 
because of the inclusion of an authenticator tag and message type information. 
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once during any secondary key lifetime. By employing the convention that the 
message in a key change protocol can be authenticated rexardless of aewaane 
counter. values, secondary key changing can be oe in error pecevery 
procedures, when message counter synchr ony is iat, This use oe key ores 
protocols will be explored further in chapter four. (13) 

In the case of the primary to secondary key change gases iated with the 
start of a terminal session, extra authentication measures are required, as a 
single primary key is used to encipher the initial pacOndary. bays for multiple 
sessions. The tag that authenticates ‘these primary to secondary rae 
changeover messages has the logical requirement to stasent a unique, 
predictable patter for each login attempted during the life of the pEsaery 
key. Without such use dependent authentication, an intruder contd masquerade 
to a user as the host by playing back the initial key change messages recorded 
dur ing an earlier session. The login authentication DES eee described in the 
next section meets this requirement without rednepoduciite the need for users 
to provide a different aurhenticetor for each login. With this login 
protocol, key change messages still use fixed tags, and a regular data message 


bearing the date and time provides the unique, predictable pattern. 


(13) When key changes are used in situations that are full-duplex, as with 
chained secondary keys, some form. of synchronization must be employed to 
co-ordinate the key change on both channels so that no outstanding messages 
are deciphered under the wrong key. Co-ordination can be achieved by having 
the terminal respond with a distinguished message when it has received a 
message indicating that a. key. change is about to take. place. Suchia 
distinguished message, which should -be authenticatable .iadependenatly of 
message counter context and is issued only once'amdéer any key, provides: a 
reference point for the key change by the host. Through the use of this kind 
of protocol, and by monitoring the values of the. meseage. concer s in use at 
the host to detect impending. counter wrapareund,; it.is : possible to 
automatically change secondary keys so that.the secondary key lifetime can be. 
adjusted to the size of the tag and the message traffic volume on the channel. 
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Login Protocol 


Commonly used protocols for logging into a host are designed to effect a 
time-independent, one-way authentication. (14) Only the identity claim of the 
user is verified by the host by requesting a secret password (or other 
personal identification) know only to the user. Below is a_ two-way 
authentication scheme based on encryption techniques and the protocols 
proposed in this chapter. It is a variant of schemes discussed by Feistel 
[FH1] and by Saltzer and Schroeder [SS1]. The login protocol is presented 
from the view of a user accessing a host computer with no mention of an 
intermediate connection through a network access device. Use of this protocol 
in a network context is discussed in the next section. This protocol takes 
advantage of the key distribution protocol described above to reduce the 
amount of work performed by the See: 

= The user enables his terminal and establishes a connection to the 

ost. 


2. The host responds in cleartext confirming the connection by sending 
the host name. 


3. The user transmits in cleartext his login identifier, then he inserts 
his magnetic stripped plastic card containing his (primary) key and 
enables the encryption module. 


4. The host locates the user’s primary key using the login identifier 
presented in cleartext. A new (secondary) key to be used during this 
session is created and transmitted using the standard key change protocol 
described in the previous section. 


(14) Such an authentication procedure permits an intruder to masquerade as the 
host because it fails to require proof of identity from. the host. Even if 
encryption is employed, the user could be confused or tricked by an intruder 
playing back recordings of previous logins because of the lack of time 
dependence in the login protocol. 
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5. The terminal deciphers the key change messages and loads this initial 
secondary key as the host also switches to this new key. The terminal 
then transmits a message confirming key receipt. .Tne host, upon receipt — 
of the confirmation is ready to engagé in secure communication with the 
user. All communication from this point on will be carried out using the 
new key. — 
6. In order to demonstrate the time integrity of the connection to the 
user, the host now transmits. the current date and time, in. ciphertext, 
under the new key. The host has already been assured of the time 
integrity of the connection because of the. correct. rece{pt of the 
confirmation of key change message sent by the terminal under the new 
key. 
7. The terminal module deciphers the date and time message under control 
of ‘the new key atid displays it on the terminal, permitting the user to 
judge the identity claim of the host and. the time integrity of the 
onnec hor: 
this login protocol prevents an intruder from "spoofing" either the user 
or the host through the use of old recorded login sessions. Although a 
conventional password authentication procedure can be followed after 
- completion of the protocol, it is not necessary if possession of the primary 
key is accepted as an identifying ticket.. Note that.the use.of a different 
secondary key for each session carries an implicit form of verification of the 
time integrity of the connection from the host’s viewpoint, thus there is no 
need for the user to respond with the time and date.measage as part of the 


login sequence, 
Key Distribution in Networks 


The terminal-host connection model presented in chapter two ‘is rae 
general | One; applicable to ei tuations as which a _host is accessed from 
dedicated or switched te (apnea lines or in. weuteat -network -enviromments. 
Below, we examine a scheme for aii iatiee al us diac ioacien tee igec 


for a specific network enviroment, and we see how “the. login and key 
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distribution protocols developed in this thesis can be used in such an 
environment. 

Branstad has proposed a scheme for initiation of secure network 
communication [Bra]. In that scheme, user terminals and host sites on the 
network each hold keys that are used for identification and for secure 
distribution of working (secondary) keys. The Network Access Controller 
(NAC), a special host computer located in a network security center, acts as a 
verifier of user (and terminal) identity and as an intermediary in the 
distribution of the keys. The NAC holds the distinguished keys of all users 
(and terminals) and host sites, and generates and distributes the working keys 
used for user/host communication. 

The key distribution protocol used by Branstad does away with the 
requirement that each host hold the primary keys of all possible users; rather 
the NAC acts as a repository for all permanent keys. This has an advantage in 
that the compromise of a single host does not result in the compromise of the 
primary keys of all users who ever use that host. Similarly, it avoids the 
need for a user to isolate his primary key from this danger by using a 


distinct primary key for each host with which he communicates. (15) 


(15) Diffie and Hellman have suggested a modification of this scheme in which 
three controllers are used and each distributes a working key to the user and 
the intended host [DH2]. The controllers are addressed with different 
permanent keys by both the terminal and the host, and the working keys 
returned by the controllers are combined using an exclusive-or operation to 
form the final working key. The scheme has the advantage that the compromise 
of a single security controller does not result in disclosure of the final 
working key used by the terminal-host pair. It does entail the possession of 
two additional keys by the user, but this does not seem to be a major drawback 
as long as all three keys can be contained on a single magnetic stripped card. 
It also requires that all three controllers be operational or that a_ protocol 
be used to handle the case when one or more controllers are down. 
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Although the key change and login “‘guthentication Beetocais proposed in 
this chapter do not assume the existence of network access controllers, it ee 
possible to use these protocols a coniinetion “with sueb controllers by 
allowing the controllers to pose as a host to the terminal at ae: a terminal 
to the host. Once the login authentication protocol has been car cied-Guk in 
this fashion between the terminal and ete controller and between che 
controller and the host, the controller need caly aidtch the eounlestiod so 
that the controller is no longer part of the connection between the terminal 
and the host. (16) Of course a different cay would be used if gue ave to 
communicate with a host directly as opposed to going through the controller, 
for in the latter case the host uses its owm key to establish ‘the connection 
to the ‘controller rather than employing the user’ s key. The important eas 
here is that the protection protocols need not be different for these two 
different modes of host access, although the keys supplied to ne protection 


modules may differ. 


Summary 


The authenticator tag design proposed in this chapter, consisting of a 
flag identifying the channel on which the message is to be transmitted and a 
counter of the number of messages transmitted - com. this: Shenue’s Eredar. a 


simple means of detecting a wide range Of message st ream mod tfticatind threats. 


(16) By chaining. subsequent. secondary key issuances rather’ that using the 
primary. key for a two-level ley change, the key change protocol described in 
this chapter is usable in network enviroments as envisioned: by Branstad,:.° In 
such environments. it is important that key. changes occurning after the login 
can take place without intervention on the part of the : network access. 
controller. 
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The key change protocol described shove: permits the use of an authenticator 
tag that can be.of moderate size as it need only. be- large enoygh to uniquely 
identify messages over the lifetime of one secondary key, an interval that is 
never longer than one terminal session,., and to prowide a, specified 
probabilistic, leyel of protection against erroneous . authentication. of 
spur iously generated messages, | 

The key distribution. protocols described permit the use of a primary key 
for extended time periods without sacrificing security, by, employing: a key 
change protocol and by using a secondary key. for. the bulk of interactive 
session message traffic. This key change protocol 4s compatible with key 
. distribution scheme proposed by Branstad ‘and-by pfttie and Hellman for’ network 
access, controller environments. Over the Lifetime of any one secondary key, 
any message that 1g recorded by an intruder amd injected into..a channel out of 
order can be positively detected. the removal of one or more messages from a 
channel by an intruder can be positively detected as soon as any succeeding 
message is received, Messages from preyjeus terminal aeasions pravide -no 
better basis. for evading the authentication . scheme than. do mesaages 
synthesized by the intruder from randomly generated bits... 
Finally, the login authentication protecel presented in this chapter 
provides a means of initializing .the conection. to.a.gecyre state with a 


minimus of yser effort. 


Chapter Four 


Detection of Denial of Service and Resynchronization 


In chapter three we adopted a tag design and protocols for authenticating 
messages in order to achieve the goal of detection ‘of message stream 
modification. This chapter discusses protocols based on request-response © 
messages and timeouts to detect denial of message service effected by 
connection blockage, and sicileante: methods to resynchronize the message 


counters at both ends of the connection. 


Detection of Denial of Message Service 


LOS 


As noted ear biee® fn our model of the terminal-host connection it is not 
possible to prevent an intruder from ‘denying message service. Denial of 
message service can refer to a wide spectrum of intruder attacks, from 
complete disruption or ‘blockage ‘of the connection to the removal or 
modification of a single message. The authentication protocols presented in 
chapter three already provide a means of detecting denial of méssage service 
that occurs as a result of message stream modification.'' The receipt of ati 
unauthenticatable message can indicate removal or modification by an intruder 
of intervening messages on a channel. If an intruder entirely blocks aebenge 
flow on one or both channels, however, the protocols of chapter three provide 
no help in detecting the disruption. In this section we develop a 


request-response protocol that can be used to verify connection integrity to 
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the end that initiates the request. The protocol will also be used in 
resynchronization procedures discussed later in this chapter. 

The request-response protocol involves the exchange of a pair of 
messages. The message issued to initiate this exchange will be designated as 
a request for status message. A message issued in response will be termed a 
status message. (A status message is also issued by the terminal to inform 
the host of successful completion of a key change as discussed in chapter 
three). Under normal operating conditions, both of these message types are 
authenticated in the same fashion as regular data messages. Associated with 
the transmission of a request for status message is a timeout. If a _ status 
message is not returned within the specified time interval, the requestor of 
the request considers denial of service to have occurréd,. 

The use of a request-response protocol by the host and the terminal 
differs. In the case of the host, automatic generation of a request for 
Status message at fixed intervals is required because the host has no means of 
predicting the arrival rate of messages from the terminal. The absence of 
messages from the user neither confirms or denies channel blockage. Thus, a 
timer in the host will initiate such requests at a rate dictated by user 
specifications. The timeout period for awaiting a response is adjusted 
according to communication channel delays. (1) | 

Compared to the host, the user is in a better position to detect a denial 


threat as evidenced by a lack of response to his commands. A user can check 


(1) During the periodic connection integrity check, transmission is not 
suspended by the host after a request for status message is sent. This 
contrasts with the use of the request-response protocol for resynchronization 
as discussed in the next section, where transmission is suspended while 
awaiting the responding status message. 
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“the status of the connection by manually issuing a ne quert _ status message, 
and being informed of the receipt of a confirming status message. By Bay Ane 
‘the user initiate the request and added when the response is avercHes we avoid 
the need to include a timer in the terminal ‘protection nodule with the 
‘attendant Viernes: in cost and complexity. Below | we shall ae “that 
‘transmission of a request for status Saale by the baratoat acute will cause 
the message counters for the connection to become synchronized, thus this 
method of allowing a user to initiate a check of the intese tty of ene 
connection also provides the user with a means for manually resynchronizing 


the connection. 


Resynchronization 


Me ssage cease and the request-response protocol seovides tha means to 
detect dental of MERSAES "service. | We now consider conneerter 
resynchronization following such a disruption. Since we eee noted earlier 
that denial of message service cannot be prevented + within the context of our 
model, it is Peaeonable: to ask why any ACCOREE at resynchronization shoute | be 
made, as such action appears to be no more tha an attempt at prevention. One 
justification is that if an intruder is Aleruatine the connection, then 
automatic resynchronization forces the intruder to continue his attack in 
order to continue the disruption, possibly are easier the tase of locating , 
the source of the ‘disruption. 

Another reason , for attempting resyachronization is that "connection 
disruption may be the result of a communication system ‘gaeaccte mot induced by 


an intruder. Although the encryption dsacrad nodules are envisioned a4 not 
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assuming primary responsibility for recovery from transmission errors and 
similar low level communication system errors (see chapter six), it is still 
prudent to provide for resynchronization | measures to be used in ., Response to 
such errors. By ‘providing mechanisms for resynchronization, the protection 
system becomes more robust in the face of some types of failures by lower 
level commun ication system components and permits the use of the: protection 
system in enviroments that provide varying levels of aceon” recovery. In 
particular, communication systems may implicitly assume that the user can 
manually resynchronize the connection if ‘Aqwer level mechaniama fail. ‘The use 
‘of encryption and the authentication protecols: .described in. this thesis: 
precludes such ‘manual Resynchrontsetion by the user, thus some automatic 
resynchronization protocol is required. a e | | 

We will enhance ‘the request-response messages described in the Taat’ 
action to allow their use for resynchronization as vel - Both the reniere. 
for status and status messages will now sontetac: as data, ‘the | reception 
Souths at the end of the connection that trananits them, in addition to the: 
transmission counter that is included in the authenticator as Figure 4-1 
illustrates this enna format (2) and labels “the two channels and the 


message counters for use in the discussion that follows. 


(2) The origin bit in the tag is omitted from the figure. and. the - diacuesion ° 
that follows for clarity. : 
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Requestor - Responder — 
tag type data 


aac bol bd es 


CHANNEL 1 


CHANNEL | 


Figure 4-1 


Model of Request-Response Resynchronization 


We segienate the denote of the -Tequest for status meseene as the 
requestor and the other aud) of the connection the responder. Referring to 
- figure 4-1, the channel from the requestor to the responder is channel 1 and 
the other is channel 2. ‘The requestor maintains the transmission counter for 
1 (Tl) and the reception counter for 2 (R2) while the eeepondec maintains the 
transmission counter for 2 (72) and the deveceton counter for 1. (R1). The 
actions of she requestor and responder described below are independent of both 
the identity of the eeudsetoe. either the host or the terminal, and of the 
circumstances that precipitated the invocation of the protocol, either a 
channel integrity check or a resynchronization attempt. 
The requestor prepares the request for status message with the value of 
Tl as the authenticator tag and the value of R2 in the data part. Tl is 
incremented and the message is transmitted. 
The responder, upon receipt of a request message the aa of which matches 


Rl, increments Rl and sets T2 to the maximum of T2 and R2 (from the request 
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message). He prepares a responding status message with the value of T2 as the 
tag and with R1 in the data portion. T2 is incremented and the message is 
transmitted. 

The requestor accepts as valid any status message the tag of which 
matches R2 or the data portion of which matches Tl. (The reason for the 
alternate authentication possibility is described below.) Upon receipt of 
such a message, R2 is set to one greater than the maximum of R2 and T2 (from 
the status message). We will now examine how the request-response protocol, 
as amended, performs to correct various connection disruptions. 

First we note that if no messages have been removed from either channel, 
the adjustment of T2 will not change its value and the adjustment of R2 will 
be the same as if any regular message had been received. Thus, if the 
protocol is invoked as part of a connection integrity check or in response to 
the receipt of an unauthenticatable message, and the counters are not actually 
unsynchronized, (3) the request-response exchange will occur with no ill 
effects. 

Now we examine how the request-response - stotaol accomplishes 
resynchronization under circumstances when synchrony has been lost. We first 
consider the case of message stream modification on one channel, which is 
noticed by the requestor receiving an unauthenticatable message (on channel 
2). In the unlikely case that T2 is lower than R2, which jequitedsa previous 
erroneous authentication of one or more messages injected by an intruder or a 


module malfunction, then T2 should be incremented to match R2. This is 


(3) Receipt of an unauthenticatable message resulting from injection of a 
message on a channel by an intruder does not affect counter synchrony. 
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accomplished by the request-response protocol since the the request: for status 
ecanaai teed by the “Pequestor contains the Sali. OE: R2. The responder will 


“increment T2 to match R2 and send a aca that will be authenticated based 


Lag! 


on “the corrected wale of 72. “the tecrepancy | roe cowmter values is Logged by 
BoE 
the eeesonder after receiving the request message we R2 in it. 


If an uanttienticatable message is catetved on channel 2 because one or 


more aeubhaés nave been modified or cieav er tron chat Shankel. ‘then R2 will be 


smaller than T2 and should be adjusted upward to agree y with r2. “72 should 1 not 


i 


be decremented to agree with R? as that would permit, the retraneaission of old 
messages by the intruder, until as 3 many ‘old messages were sent t by ve as had 
been removed. (4) The responder s must inform the requestor at the yatta of 12, 


but he cannot send a message that vill be authenticated by a tag that matches 
R2 without reweing. a tag. This is. anaes: che alternate authentication 


PS en 


procedure for status message is saployed, allowing the requestor to accept the 
response and increment R2 to match T2. | | 7 

For the alternate authentication eae to Regis BEODOES?: it Cis 
weseeaity. that the requestor ouepend tranemission pending receipt of the 


status message. Otherwise, Tl will not match the Rl value that was 
transmitted in the status message. aa “This ie not an saeeasonab le 
nae : 


restriction on the “requestor as failure ‘to receive a | prompt response to the 


(4) Such intruder retransmission could interfere with valid user-host 
cgamunication .as it. may not be practical; fon . the comgunication systen:, . 

especially at the terminal, to retain old messages for retranemission and new 
messages that might be transmitted under already used message tags may be 

different from the removed “messages. 

(5) If additional bad messages are received by the requester, they are logged 
but no more request for .statys, measagea ate trenewitted, 69 as nat.to: 
interfere with the alternate authentication procedure. 


AoE RE 
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Tequest meeeene is ang iceeee of 3 more Ber 2008 peopleme: eee. Eecetpe of the 


we 


vesponse, the number of messages “removed or destroyed is Logged by noting the’ 


difference between, ‘the tag and R2. 
The resyuchronisation saceuarios described above preeine rine ‘synchrony 
has Sean ‘lost. on only one of the two Shednals and that no “active dental of 
Ba: Yat oq 


eiivice. via message blocking or mosense modification is oceurring « on jerenet 


net 


a ehawiel: If ‘ayéck-Ouy. is Lost on both channels before the | reaynchrontzation 
procedure is conplete, or if r messages are being blocked or mod ified on Eiger ner 
chaanal then ‘the seocedare will not ures leaving the requestor(s)_ of. the 
fequset veacoine protocol waiting for an shtieasie status mgeeens: this 
situation will be detected by the automatic timeout for the status message in 
the case of a host initiated resynchronization, In the case of a user: “or 
terminal initiated resynchronization via the snusae ele ters Protocol, the | 
* next automatic integrity check from the host vill Geren’ “the fase to 
reaynchronise. | | 

Once the . host ye aware | of the problen ; on level of r recovery 
atratesy is ‘employed. , new key will be tasued by ‘the ‘howe, and noseage 
traffic will resume from Bae point. this is possible because the ey change 
messages are puthenticated independently of counter synchrony. ; Although this 
key change “approach “to pen eacant tehtne synchrony my seen a drastic ones tt 
seens justified in light of the circumstances vhich are required to invoke it. 


(6) Because severe chs cepg ss of the connection results in this change of ey, 


— : 
(6) Unfortunately, Sagar ting’: to. a ie thease deca sie: user oe ‘the. 
information describing the extent of message leat as reported thtough the use 
of the request for status and status messages. The information could still be 
provided if the status message sent in response. to...completion of. the. key. 
change, or some other special: ‘wansage: sent! denetiately’thereaftet “tarried| 
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it reduces the desirability of such acareank for an intruder who is tryice to 
subvert the protection measures. A timeout is also associated with the key 
change protocol, setting a limit on how iene she host will wae: for the 
confirmational status message, so that a failure to successfully issue a new 
key within an appropriate time iieeeal will result in atandouine the 
connection. By assoctating a user apecifiable Limit with the number of times 
this form of resynchronization will be attempted dur ing shi login session, the 
user can maintain ‘control over the use of: resources in such recovery 
procedures and can catise the protection spaten t6 abandon the reriinet tat 


connection. 
unm ar 


We have described a hierarchic approach to dealing with resynchronization 
and have integrated this approach with denial of message service detection. 
. This integration is achieved by using a request-response protocol as the basis 


for both resynchronization and detection of channel blac keraers When the host 

: aa ; ae 
or terminal attempts to establish synchrony after receipt of © an 
unauthenticatable message, first an i teape is aaie to restore synchrony by 
initiating the request-response protocol on the other channel. If synchrony 
has not been lost or has been lost on only one channel, chen this procedure 
will succeed, verifying the time integrity of the nencerton: If this 
procedure fails, or if a periodic connection integrity check fails, a key 


change is initiated by the host. Even if synchrony has been lost on both 


channels, the key change can succeed and establish a new reference point for 
: ae ae 


— ; 5 . ie <i H 5 “a 
information about the values of the terminal reception and transmission 
counters before the key change occurred. 
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resumption of message exchange in a secure environment. Should the host not 
receive confirmation of the key change, within an appropriate time interval, 
the assumption is made that denial of message service is actively occurring, 
either as an intruder threat or as a result of a serious communication system 
failure, and the connection is abandoned. 

The protocols presented in chapters two, three, and four will be 


described in greater detail in a sample implementation in chapter six. 


Chapter Five 


High Priority Messages 


The discussion so far has ignored the need to support high priority 
messages sent by the user to the host to siteot aone utvede control fee clog: 
ae ae to halt a runaway ieee process ase stop aaanted out put arriving at 
the terminal. This chapter éctande the cbaneeciae: ebdel es dhelude Bich 


priority messages and develops protocols for handling them. 
Extending the Terminal-Host Connection Model 


Most interactive computer systems embody the concept of a high priority 
message sent by a user at his terminal to his computation at the host. The 
specific messages used with different systems and subsystems vary. We presume 
that the texts of the various high priority messages are embedded in the user 
data sent on the terminal-to-host channel, and that some high priority message 
processing (HPMP) facility in the communication system at the host scans all 
user data received on a connection, recognizes the high priority messages, and 
acts on them. Because the host communication system may employ buffering 
between the HPMP facility and the rest of the connection, it is frequently 
necessary to provide some means of alerting the HPMP facility that a high 
deinrity message has arrived at the host, so that the HPMP facility can search 
the buffered input for the message. The protocols developed in this chapter 


are designed to provide an appropriate signal, regardless of the buffering 
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strategies employed in the host. In the next chapter, tue host response to 
the signal, given various buffering strategies, is discussed. 

The basis for the high priority message protocols is the addition of a 
special "attention" channel to the connection model, as illustrated in Figure 
5-1. The attention channel is used only to signal the host end of a 
connection that a high priority message has been sent on the regular 
terminal-to-host channel. Care must be taken in the implementation of the 
host end of a connection not to buffer the attention channel, so the host 
protection module is never blocked from noticing a signal on the attention 
channel pending some asynchronous event. Note that this additional channel, 
like the other two, may actually be japicecceed in a variety of ways by low 
level communication system protocols, including the multiplexing of a half or 
full~duplex connection. (1) Because tha attention channel is modeled as a 
separate channel, an intruder may have no difficulty in distinguishing 
messages transmitted on it from regular message traffic. Thus we cannot 
conceal the transmission of high setoeity-wekeagee and must be content to 
prevent the intruder from perpetrating undetectable acts of message stream 


modification or denial of message service on this third channel. 


(1) In situations where a separate physical channel is not available to 
support transmission of high priority messages, some form of "out-of-band" 
signal may be used to simulate the transmission of a message on this channel. 
One commonly used protocol for transmitting a high priority message on a 
half-duplex connection involves sending a "line break" on the connection so 
that the terminal may gain control of the connection. The terminal can then 
send the text of the high priority message, having forced a line turnaround to | 
occur. 
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regular regular 
channels channels 
Terminal Keene-----} Intruder |<-<-<-----— |p 
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attention ‘attention 
channel . channel. 
Figure 5-1 


Connection Model Augmented to Include the Attention Channel 


Protocols for High Priority Messages 


The protocol presented below for the transmission of high priority 
messages permits wide latitude in the number and nature of messages sent and 
the buffering strategy used in the host. It is derived from the technique 
used in the ARPANET host-to-host protocol for transmission of high priority 
messages. [ARP]. Two new control message types are introduced to support this 
protocol: attention and data mark messages. The attention message is the 
only message transmitted on the attention channel. The data mark message is 
transmitted on the terminal~to-host channel. 
Three steps are involved in the transmission of a high priority message. 
First, the text of the high priority message is sent on the regular 
terminal-to-host channel. Next, an attention message is constructed and 


transmitted by the terminal protection module on the attention channel. (2) 


(2) In environments where an existing communication system protocol is used to 
support tranamission of high priority messages, the attention message is 
transmitted in conjunction with this existing protocol and serves to securely 
authenticate the existing protocol’s claim of receipt of a valid attention 
message. 
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Finally, a data mark message is constructed and sent on the regular terminal 
to host channel. (3) 

The host protection module must be farther out on the connection than the 
HPMP facility, as high priority messages must be deciphered before the HPMP 
facility can process them. Thus, the attention message serves to notify the 
protection module that a high priority message is enroute, while the data mark 
message locates the end of the text of the high priority message in the 
regular channel and marks the position in this channel that corresponds to the 
transmission of the attention message on the attention channel. (4) Upon 
receipt of an attention message and the matching data mark, the host 
protection nodule signals the HPMP facility of the arrival of the high 
priority message. Discussion of the details of the signalling, and other 
interaction with the host communication system in conjunction with the 
processing of high priority messages, is deferred to chapter six, as these 
details are dependent on the buffering strategy employed in the host. 

Since the attention channel is ateeinee een the other two channels, it 
has a distinct pair of message counters associated with it. The transmission 
counter for this channel is located at the terminal end of the connection and 


the reception counter is at the host end. An attention message tag consists 


(3) In systems that use only one type of high priority message, e.g., a "quit" 
on Multics, no text related to the high priority message need precede the data 
mark message. Receipt of the data mark message is sufficient to transmit the 
desired control signal and mark the position in the regular terminal-to-host 
channel that corresponds to the transmission of the attention message. 


(4) As the data mark message is a protection module control message, it does 
not appear in the cleartext output from the protection module, and it may need 
to be translated into a data mark character to delimit the high priority 
message text for processing by the HPMP facility. 
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of the usual terminal origin identification and a transmission counter value 
that indicates the number of attention messages that have been bvaneasteed 
since the initialization of the attention phaiiels Because attention esenaues 
are sequenced on a separate edbatae: they can be received and suchencicated 
independent of messages ctalanitted on the regular channel. (5) 

Each data mark message carries an authenticator tag ct the same form as 
other messages on the regular terminal-to—host channet. Included in the data 
portion of a data mark message is the value of the attention message 
transmission counter at the time the data mark inpeane wae Slaten bead: ‘This 
serves to associate data mark and attention messages. Hence, a given data 
mark message can be correctly paired with a matching attention message, 
despite interference on any channel. This design of the data mark and 
attention messages also links together, for datection of ieaial of eccenee: 
service, the attention and regular channels. | 

Figure 5-2 illustrates the use of the protocol described above in the 
transmission of a high priority message. High priority message text in a user 
data (DATA) cescaeel an attention (ATT) message, and a data wat (DMK) message 
are shown enroute to the host. The message formats displayed are the same as 
in chapter four: tag, type, data. Values for the régilax teredial-ecchost 
transmission (Tc) .and reception (Rc) counters and the attention message 


counters (Ac) also are shown. 


(5) We shall see in chapter six that this is a neceasary property for the 
attention message because of problems asggeciated with recognition of 
enciphered attention messages by facilities further out than the protection 
module. 
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Figure 5-2 


High Priority Message Transmission Scenario 


Although resynchronization and integrity checking could be carried, out 
for the attention channel separately, theee functions can be performed 
simultaneously for all three channels without introducing o@oy new message 
types. This is accomplished by including the appropriate attention channel 
‘Message counter value in request for status and status messages (6) and 
expanding the counter update procedures to include this additional channel, 

This extension of the resynchronization protocol is not complicated since 
this new channel does not enter into the alternate authentication scheme for 
Status messages. Receipt of a data mark or attention message that does not 
have an acceptable authenticator tag, or receipt of a message on the wrong 
channel, results in initiation of the resynchronization protocol just as does : 
receipt of any other "bad" message. A new context for initiating the 


resynchronization protocol now exists: receipt of a data mark message fdr 


(6) The attention channel transmission counter is included in the data portion: 
of a request for status or status message trangmitted by the terminal while 
the reception counter for the high priority message channel is included in 
such messages when transmitted by the host. 
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which no matching attention message has arrived. This situation indicates 
dental of service on. the high priority channel ead is -;handled by sccepeone 
the high priority message preceding with the date mark message and initiating 
_ the resynchronization protocol as though a unauthenticatable message had been 


received. 


Summar y 


This chapter extended the connection model of chapter two to include high 
priority messages and the facilities necessary to process them. A new channel 
from the terminal to the host was added, and two new message types, attention 

and data mark messages, were introduced to support tranamission of high 
priority messages. The data portion of request for status and status messages 
was extended to contain the values of. the message counters for this new - 
channel. The resynchronization and detection of denial of message service 


protocols were modified to include the new channel. 
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Chapter Six 
Communication System Interfaces 


In this chapter we refine our ¢ommunicatton path model, examining it not 
simply as a terminal-to-host connection, but rather as & comectton between a 
user and his computation. Our point of viéw in examining this cormection is 
based on the reaéarch of computer input/output systetis by Clark [Cla]. With 
this view in mind, we answer the question of where to position the protection 
modules with réspect to the various hardware and software niodules at both the 
user and computation ends of this ‘ébineteton: The strategy we adopt is to’ 
position the modules to eicompass all multiplexed system facilities, as well 
as all physically unsecured facilities. This simplifies the task of verifying 
the security claims of a system by restricting the appeatance of cleartext to 
environments that are private to a single ‘user, Also discussed are the .inipact 
of different input buffering strategies on host protection module structure, 
methods for promptly recognizing high priority tressages, and methods for 


echoing characters effictently. 


Effect of Security and Functionality on Pos{tjoning 


Two major factors influence the positioning of the protection modules in~ 
the connection between the user and his ‘emote computation: security and 
fmictionality. 

With respect to security, the encryption modules’ provide protection from 


certain forms of intruder threats directed against that portton of the logical 
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connection that is "between" them. Certainly all of the physically unsecured 
portion of the connection need be between the acdules) but it also is useful 
to encompass gevedia physically secure parts of the communication system. The 
design. and verification of the correct aperation. of the portion of the. 
communication system that is between the protection modules is simplified 
because that portion cannot compromise the. connection. any more than the 
intruder of our model. 

Of special interest are the parts of the communication system, whether 
physically unsecured or not, that are. multiplexed among many users. A 
fundamental principle in the design of secure systema ia the avoidance of 
unnecessary common mechanism [SS1], for mechanisms that. are eiadan es more 
than one user provide a..potential path for unwanted.user interaction. Because 
the protection modules are associated with individual logical connections, 
they need not be implemented in a multiplexed facility. of the communieation 
system. Indeed, the encipherment provided by. the protection modyles can 
assure the logical separation of individual connections ag.they pass through — 
venious wultaplexed facilities. Examples of Scmmmioatian system hardware 
facilities that frequently are multiplexed among many-‘connecttons; and thus: 
should be positioned between. the protection..modules, are terminal 
concentrators and host front end processors. (FEP’s). Examples of software 
facilities that frequently are multiplexed are buffer management modules for 
multiplexed channels. Thus, we will position the protection modules so as to 
encompass all multiplexed facilities in the communication system, allowing the 
protection modules for a single connection to operate in an environment that 


is private to that connection. This positioning strategy is illustrated in 
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Figure 6-1, which shows the path through various communication system modules 


that might be followed by a typical connection. _ 


communication 


network 


physically. 
unsecured _ 


ASP renew me mem meme > | 
¥: Eee Peay, 


Koew--e---—---=-potentially multiplexedr------—>| 
Figure 6-} . 
_s-.., Protection Module Positioning, Strategy 


A different view of security con Leal to an’ alternative positioning ‘ 
strategy. If the major security concern 1s. preventing messages from ever 
appearing in a physically tinsecured eivircent. in cleartext, ‘and “at is 
considered less apoteaae to. "Prevent leakage among logical connections, ‘then 
it can be argued that the modules ehoala “be 1 positioned” at the boundaries 
between the physically secure and unsecure portions of the communication path. 
Then input/ out put can be forced nA pass cheough ‘the encryption algorithm, ‘thus 
assuring that any data that enters the unsecure enviroment is protected tron 
unauthorized! d{sclosure. “This alternative ee: “strategy wilt - almost 


aliaga. ‘eeealt. in multiple Andinidual Gieartext ‘ es aaa being handled , in a | 


multiplexed fentlity somasiiere. - bakjave  tapeqyed ., poftware.. 
bi phaiaiaaa techniques vend Rabat. ayaten design will make Less. desirable, e 
this particular harige against failures, by: host, er. “tarminal systems to... prevent. 2 


meaeages, rome: _ appearing 4n a | physically sungecured ‘soritoment. in cleartext, 
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Moreover, as we are interested in providthg “secure ‘commun féation eee hbst: 
that have diverse ieee communities, thié strategy seems ufiattractive as not’ 
all users may have terminals equipped with protection modules. If provision 
is mide” at the host to circumvent the encryption scheme and the protection 
module to permit cleartext Communication, 80 as: to’ aeconodate users ‘not 
' utilizing fee “protection module,.. then. the briginal, juatifieacion for the 
alternative strategy no longer holds.” | oe 
With respect to functionality, protection modules are constrained to be 
below the portion of the communication system that engages in syntactic 
processing of message contents. These constraints of the communication system 
functionality are primarily a factor in positioning of the ‘protection module 
at the host, as almost all processing of this nature is performed at the host. — 
With respect to output from the host, encryption can be performed only after 
such transformations. as device~-specific code converaion,. white-space 
optimization, and formatting. With respect to input to the habe: messages 
must be deciphered before such ivehurstuatlons as canonicali zation, — 
character detection, erase-kill processing, — translation, escape se quence 
processing, character echoing, and high priority message recognition can be 


performed. (1) 


(1) Character echoing and high priority message recognition will be discussed 
in detail later in this chapter. ‘Canonicalizattion refers ‘to the arrangement. 
of input data into a form that removes the ambiguities introduced by. the use 
of carriage motion control characters [SO]. Steak characters delimit the 
effects of erase-kill processing and canonicalization and cause the input to 
be’ forwrrded to higher levela for possible further ptecessing.' Escape sequence 
processing refers to the transformation of multi-character sequences used to 
enter charactérs that have control meanings ‘without *avoking the associated 
control functions, into their single character representation. Formatting of 
output involves conversion of tab#-to ‘spaces ‘for termidals that do mt support: 
hardware tabs and insertion of newlines in output when strings are longer than 
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At the terminal end of the connection, the security requirements and 
Fimceasaniaey constraints dictate positioning the protection module between 
the terminal and the rest of the communication system. Such components as 
terminal concentrators, line adaptors, and modems will be "further out" on the 
connection than the protection module. This strategy provides substantial 
flexibility in configuring terminal subnetworks in which not all he terminals 
may be using the protection modules. At this end of the connection, it seems 
reasonable to implement the protection module in hardware, as this end of the 
protection system has been designed to require a minimum of processing power. 
With the current capabilities of large scale integration, it seems plausible 
that the protection module hardware could be fabricated using a microprocessor 
and a special chip for the encryption algorithm. 

At the host end of the connection, the security requirements and 
functionality constraints will usually require implementing the protection 
modules in software. (2) By implementing this protection module in software, 
the memory protection machinery in the host computer can be used to provide a 
private environment for the execution of the protection module for each 
connection, and the protection modules will be beyond any multiplexed buffers 


managed by the host operating system software. (3) 


the line length of the target terminal. White space optimization refers to 


replacement of multiple spaces with tabs and of multiple line feeds with form 
feeds. 


(2) The addition of a hardware encryption/decryption instruction to the host 
instruction repertoire may be required to obtain efficient operation. 


(3) The host’s memory protection machinery also may be used to protect the 
modules from user level programs that may damage or circumvent them. The user 
level programs might inflict damage as a result of errors or might be "Trojan 
horse" programs [SS1] supplied by an intruder to subvert the modules and 
permit the intruder to assume control of the user’s computation by disabling 
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rupieeneak ion of the protection modules at the host Sa uokivete modules 
private to each user computa ction also has tie ndvantanes with respect to the 
egies and verification of the modules themselves. First, at this level in 
the software of the host, modules can usually be implemented in an environment 
that is cbaduddve to the aeeree of a well-structured protection module, 
permitting the use of high level; structured oc cateuntne languages and 
mult iple-process (rather Snag ineareupe) “Ocianieacion of the control 
Beer tea (4) This means cist the modules can “be cee in design and, 
consequently, their correctness may be easier to verify because they need not 
deal with means commun ication system details: Second, it may be possible 
to isolate many of the characteristics of the phyaical connection from the 
protection module, presenting it with a simple virtual comection interface. 
The pGaminioarton system configuration siieacuer ities need a be programmed 
into the modules. For example, although che cescsesle are designed to pperate 
in a full-duplex Bivivepments- they can be ut tlined aa sicker half or 
full-duplex shiva teal coimeneiowe if the interface presented ‘ the modules 


reflects a virtual full—duplex connection. 


or subverting the protection module. Whether:.or not the. host protection 
module is part.-.of the security kernel {Sch}. of the host: syatem depends upon 
the security policy to be enforced. It will be part of the kernel if the 
security. policy requires certain users. to: employ a. Rude cat reg Se 
BOeeLS otherwise not. 

(4). Such facilities Sieke not Be available if che host grotaction module were 
implemented in a front end processor or in a restricted environment in the 
lowest levels of the operating system. 
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Buf fering Strategies 


Any communication system for connecting, users | ith interactive 
computations must deal with the fundamental ‘problen of _nyachi’oniiing the 
arrival of messages from a user with elie demands, for input from his 
computation. Many systems achieve the necessary eynchronseation by providing 
one or more buffers in the connection between the user and his computation, 
thus allowing the user to work ahead of tts demands for input. (5) The 
positioning of these buffers has “impact on ‘the eerie of the host 
protection module, which impact we will now explore. 

' Figure 6-2 illustrates sdusible buffer scgiticie: In this nas ene 
box labelled EPM is the host encryption protection nodule tor ‘the connection, 
and that labelled CMM is a connection management nodule: that. “performs ‘the 
various required syntactic franeformatloni on the input following decryption, 
including recognition and processing of high beiority y mesaagen. For aifferent 
commun ication ayetee organizations, ‘buffers may appear a at positions A ‘By and 


Cc in any "combination. A buffer at any of these. positions can provide the 


central synchronization of arriving input and “denands for Anpor from cn 


computation. 


(5) This synchronization problem also can be handled by explicitly prohibitiag. 


the user from entering data at his terminal until his computation is ready for 
that data. A communication system can enforce such synchronization by 


transmitting a control character to the terminal to “lock! :the:kdyboard wyen — 


the computation enters a state where it is not accepting ‘input, and = then 
transmitting another control character to "unlock" ‘the keyboard when the 
computation is ready to accept-: input. -H this approach to achieving 
synchronization is employed, the following discussion acne ee ane ite 
‘impact on the protocols is irrelevant. — 
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buffer buffer user 
=> A —=> -——>f° Bo [===> —— --->{ computation | 


encryption connection 

protection management 

module module — 
Figure 6-2 


Buffer Position Possibilities for Host Input Channel 


Buffer A represents the buffering of input to the host in front of the 
protection module, perhaps by a front end processor or by ‘operating system 
facilities. Because this buffer is berwend the protection modules, it may be 
part of a ecmmain buffer saiapement mechanism that supplies: messages upon 
demand to all protection modules in the host. This buffer is not necessary 
and its presence only complicates the operation of the protection module, as 
we discuss below. Buffer B is also not necessary if the connection management 
module is implemented so that it immediately accepts the cleartext output from 
the protection module. As will be ae in the next section, buffer B 
complicates the processing of high priority messages. Buffer C holds input 
processed by the connection management module but not yet requested by the 
user’s computation. Location C is the preferred position for the buffer that 


synchronizes data arrivals with computation demands for input. 


Response to Timeouts 


Buffer A interferes with the processing of timeouts used to detect the 


failure of a status message to arrive within a predetermined interval. When 
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buffer A is employed, the protection module first must request and examine all 
messages in buffer A before deciding that the occurrence of the timeout really 
represents a failure to receive a status message. Thus, with respect to 
processing of status timeouts, it is preferable for the protection module 
always to receive input from the connection upon its arrival at the host, 
without the existence of buffer A. Such an arrangement. is possible because 
the cleartext output from the protection module can. be forwarded to buffer B 


(or to buffer C if buffer B is not employed). 


High Priority Message Processing 


In order for a high priority message to have its desired impact, the host 
must recognize and process it quickly upon receipt. Quick processing is no 
problem if. buffers A and B are not present, for the connection management 
module will. notice high priority messages as they arrive, independently of the 
rate at which the computation demands input. (6) In this case the - high 
priority .message protocols of chapter five are not needed. The host 
protection module can still match data marks to attention messages and keep 
Prac of the various eoubeess but it need not signal the connection 


management module when an attention/data mark pair arrives. (7) 


(6) The standard communication system flow control protocols prevent overflow 
in buffer C, as their action is not inhibited by the presence of the 
protection modules. - 


(7) If input synchronization is accomplished through the use of keyboard 
locking, a high priority message is usually sent ‘by “transmitting “an 
out-of-band signal to the host. The host then responds by sending the control 
_ character that causes the keyboard to be unlocked, allowing subsequent 
transmission of. the high priority message text from the terminal. In this 
case, although the data mark message is not necessary, the attention message 
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If buffer B is present, the connection management module may not notice 
high priority messages as they arrive. In this case, the protection module 
must signal the connection management module when a high priority message has 
arrived. The protection module, upon receipt of a data mark, does three 
things: increments a counter of data mark messages received, places a data 
mark character in buffer B, and signals the connection management module. The 
data mark character is placed in the buffer s0 that the connection management 
module iwel-abes to stop processing input from buffer B. The counter of the 
number of data mark messages received is used. by the connection Reeernent 
module, in conjunction with a counter of the niiibee of ‘data mark characters it 
has examined, in order to synchronize data mark characters and signals from 
the promotion acdute’. (8) 

Finally, if buffer Ais present, some facility must be provided to 
recognize attention messages. and forward them to the protection module, 
bypassing buffer A, and the protection module must request and examine the 
contents of buffer A to locate the data war message. Figure 6-3 illustrates 
this configuration, depicting the protection module, buffer A, and the 


attention message recognition (AMR) facility of the communication system. 


sigtial ‘use by the standard 


¢an be used to authenticate the out-of—ban 
commun ication protocol. 
(8) This is an example of the eee waiting" problée’ as described by Saltzer 
[Sall]. 
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—----> to the connection 


connection -----> 
management, module 


Reena ane ee! M 


attention channel 


attention SEES encryption 
message ...........; pretection _ 
recognition module 
facility 
Figure 6-3 


Attention Mesaage Recognition : 


If the communication system employs a aed tal protocol for signalling on 
the ditendioa channel under regular (unencrypted) “ctreumstances, then this 
same pEatocol. can be used “in Sonjuaction with “the transmission of the 
* ecreation message ‘to notify the protection module that! ‘a high priority message 
is enroute. Under such circumstances, the AMR facility takes the attention 
“message that was sent using this standard protocol ‘and forwards it to the 
“protection module for processing. This attention message is given to the 
" peeEee eine module in front of regular input ‘that may be in buffer A, since the 
attention “usieage logicaliy belongs on the attention channel. The protection 
“module can decipher and authenticate the attention message and request the 
contents of buffer A. These contents are processed by the module to locate 
' the data mark message. If the data mark message isnot tocated in the buffer 
contents, an integrity check is initiated, raaulting , in flushing the 
connection to the host protection module and Jocating of, the data mark or 


_ ewtag out and changing heya. 
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In an environment eve no stanaucd: protocol’ is used to support 
transmission of an attention signal and “buffer A is employed, a different 
approach must be upto. If an attention message had to be dec iphered to be 
recognized, then the AMR facility would have to be able to decipher messages 
4n order to recognize the attention message and forward it to the protection 
module. As buffer A and the AMR facility may be part of the common mechanism 
of the communication facility, this is not acceptable and below we show how to 
ameliorate this situation. 

In chapter five we saw that attention messages are constructed using only - 
the value of the attention message trananission counter, the terminal origin 
identifier, and the type identifier for attention messages. Thus, the host 
can construct the enciphered image of the next attention message that will be 
transmitted by the terminal, under the cored’ per ondany key, and. _pass this 
bit pattern to the AMR facility as the basis for neccent tion of an ec iphered 
attention message. (9) Upon arrival of an attention message that matches _the 
template, the AMR facility feryard® it to the protection mo module eheee Of oy 
messages in buffer A. The protection module processing from this point is 
same as if a standard communication system protocol had been used in 


conjunction with the transmission of the attention message. (10) 


' (9) A new attention message template must be distributed at the beginning of 
each session, after ‘every key change, and whenever the value of the host 
attention message counter changes. The host protection module can distribute 
several templates to the AMR facility at ond time, corresponding to the series 
of attention messages to be tranemitted by the terminal module. This 
eliminates the likelihood of an attention messaje arriving and not being 
recognized by the AMR facility because the facility has not yet received the 
next template from the host protection module. 


(10) Note that even if the enciphered attention message template has been 
compromised by the communication system and the attention message received by 
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Should an attention message be removed from, the. attention channel, -the 
next attention message tranemitted by the terminal will not match the template 
held by the AMR facility and will not be recognized as an attention message. 
‘A similar situation arises if an attention mesgage is madified enroute to the 
| host. In either case, examination of the "bad" -attention message by the... host 
protection module, in the course of normal message processing, results in a 
channel resynchronization, and the user ig notified of the loss of the 
_attention message. The maximum delay that can accur in recognition of. an 
attention message Galax these circumstances is dictated hy the timeout _ aed 
for periodic connection integrity checking (are chapters, four, md six). (11) 

By using the mechanism proposed above to solve. the problem associated 
with attention message recognition, we are able to yse the.kest protection 
~~ module whether or not buffer Ais present and whether, Ar. mot a standard 
communication syatem protocol is uged in Sanh wmction: with the .ranamission of 


attention. messages. 


Echoing 


The term "echoing" ig applied to a variety of character, processing 
techniques performed on asynchronous communication lines usually operating in 


full-duplex mode. In its simplest form, echoing may merely involve the 


the protection module Ty ; i be 
disrupting. the input . to. the user’ a. _gomputation, (aa. “Long, a8: no input,. is 
discarded by the proteetion. or the. connec tien. menagement,..modules) . because 
there is no matching data mark message . to confism. . transmission. of the 
attention message. The connection integrity check, initiated by the host when 
it fails ta locate the data mark, measege, will.detect. this. iesiamases of . seine 
atention, message and. | Feeynchronize the.connection. .. 


. (11) If this timeout is set to a short extuah: deigreal:.; thos. : ae may net “ie 
necessary to propagate an attention message. template.as noted above. pee 
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transmission back to the terminal of every character sent to the host. This 
type of echoing is sometimes designated as echoplex mode and is used primarily 
as a means of verifying the reception of characters ‘transmitted over voice 
grade lines. More elaborate echoing may involve a substitution for some 
‘characters -on a one-for-one basis or even a variable length 
substitution~for-characters received from the user. terminal. (12) 
Additionally, echoing may be co-ordinated with host output messages so that 
asynchronous fateractions do not result in haphazard mixing of user input and 
host output on the user terminal display. The echoing connection seems to 
belong in the connection management module of the commun ication system 
hierarchy, for it must analyze cleartext. . Such placement of the echoing 
function, however, can cause inefficient use of cotinection bandwidth and 
potentially unacceptable teal time delays for the user. 

First, we note that the use of the: protection protocols eliminates a 
fundamental reason for employing echoplex mode echoing. Thies is because use 
of the protection modules guarantees, with high probability, that the 
characters received by the user’s computation have not been altered in 
transit. (13) Thus, as long as some means is provided for displaying each 


typed character on the terminal, so that the user can determine if he has 


(12) This last characterization of. echoing includes. techniques that analyze 
terminal input in an effort to complete the composition of an input line, or a 
portion thereof, on behalf of the user. Such” processing is very sensitive to 
the subsystem with which the user is interacting and thus’ is usually performed 
within the user’s process at the nose [Bob] . ; 


(13) Because the host is not wetiveiy echoing each character typed by the 
uger, this configuration does not provide the rapid detection of severance of 
the connection that host-based echoing provides. This may be a problem in 
situations where the user is typing text: for which he expects no response from 
his computation, e.g., entering‘text into a file for later editing. 
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typed what he thought, he typed, there, is no nged tp.involve the host, in 
echoplex mode echoing. ; ay ae 
if. Rost-based echoing 18 used with. the protocols developed in this 
thesis, because the echoing is more sophisticated than, echoplex mode, echping, 
.each character input by the user would be,encighered jn a separate message 
_ block and transmitted, to the hogt,. where the block would be decsdphered and any 
required echo procegsing, would be performed, The, result of that, proceasing 
would be enciphered in a message block and transmitted to the terminal . where 
At would be deciphered. and, displayed. Thus,.each character tranaaitted by the 
ferminal would go through the encryption/derryption glgorithm a total of four 
r times under these circumstances. 4) This encryption qverhead,. when added to 
_the round trip trangmission time and host Processing, delays usually associated 
with echoing, may constitute an unacceptable rea] time delay for a user at his 
_terminal., Of course it shoyjd be remembered, that the user generally transmits 
,fata to phe host af, a much lower rate that he receiyes, it and the effective 
bandwidth provided by this approach ta echoing. may be..acceptable if ..the 
Protection modules, Are fast enough, 92000 © ones gr tad ss too 
- Io many. hosts echoing , is performed by. some. mu} tiplexed. facility, e.g., a 
front end processor. Yor the security reaagaa, neted. earlier, . it. is not 
desirable to permit, a multiplexed . facility tp. contain the host, protection 
pmodule in order to. perform echoing. . Becpuse, the echoing performed by. a 
multiplexed facility is usually relatively simple,,as opposed. to, sophiaticated 


echoing, that .requires..a private, hoat—based process, the solution preseated 


(4). this 5 crenbalenion ef blocks cesta iuiig: single characters. results, in block 
” space ‘utilization of about 5% and 10% for Lucifer and NBS block sizes 


respectively. 
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below alleviates the problem of multiplexed facility” echoing, as well as 
reducing transmission and encryption overhead. 

As an alternative’ to host-based echoing in situations not requiring 
extremely sophisticated echo processing, we propose the addition of an 
-echotng module to the protection modulé’ located at the terminal end of ‘the 
connection. The degree of sophistication provided by suth a module can ‘vary 
over a wide range depending upon the desires of the tiser Community.’ Details 
of local echoing procedures have been developed as the nakote’” conckoited 
Transmission and Echoitig (RCTE) Option in the ‘ARPANET TELNET protocol [ARP] 
for use in situations where the time delay assoéfated with conventional remote 
echo tag is considered unacceptably long, e.g.; tai satellite connections from 
continental users to the Aloha system in Hawaii, or when the host does not 7 
wish to be burdened with the extra processing. The ‘Telnet’ ‘system alas: 
provides a host level protocol option Yor’ such’ local echoing [tcc]. ‘the 
concept of using a microprocessor to implement such’ a° local’ e¢hotng module has 
already been suggested in connection with packet radio networks [kar]: ° This 
approach to echoing eliminates the real time: delay ‘ahd Snefricteat block’ space 


utilization problems noted above and does not: require the partictpation of any 


cd re 


multiplexed facility in the echoing. 

If a private process or task is provided ‘td wonitor terminal input’ and 
the connection management module is contained ’ if * this “process, then 
sophisticated forms of echoing can still be’ provided’ by directing the terminal 
echoing module to transmit (for echoing) only those’ tharacters that require 
special processing. This minimizes the impact...of. .echo. processing on. the 


‘connection performance since most characters, are lo¢ally echoed and’ only a 
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few require echo processing by the host. Since sophisticated echo processing 
usually entails the use of private tasks or processes dedicated to monitoring 
terminal input, this scheme does not imply a drastic extension of the 


functionality already provided in such enviroments. 


Summary ; 


In this chapter we have examined factors influencing the positioning of 
the encryption modules in the Caumen ication. systen. By “poaltionine ” the 
modules above the level of multiplexed facilities is the Bodum ieecion ‘aysten, 
the security guarantees _ Provided by the modules cover much of, the 
commuication system. This results in reduced Souplextes in verifying the 
secure operation of both the protection modules “and encompassed portions of 
the commun ication system, and ‘increased flexibility in configuring diverse 
user terminal networks. Problems associated ‘with eecomaition of attention 
messages in various host commun ication env ircomedta were examined | and 
techniques of supporting high priority message , transmission in all of these 
environments were presented. Problems associated with a broad spectrum ‘of 
echo ing - techniques were examined and it was proposed that, in the case of 
simple echoing on asynchronous lines, some variant of a pamote eoucealled 
transmiss{on and echoing protocol be employed to reduce real time delays and 


to ‘improve bandwidth utilization. 


Chapter Seven 
Control Structure of the Protection Modules 


This chapter consolidates ie, discussion of the earlier chapters by 
presenting a description of both the terminal and host protection modules. 
This detailed description brings out aspects of the interaction of the 
protection protocols that is not evident from the independent descriptions of 


the protocols in earlier chapters. 


Message Formats 


Seven types of messages were introduced or implied in the discussion of 
protocols in earlier chapters. Formats for these message types are presented 
in Figure 7-1. No specific message block size is presumed in — this 
description, thus such details as the width of the various fields and unused 
space will be ipacved:, (1) These message formate can be used with either the 
128-bit Lucifer blocks or the 64-bit NBS blocks. 

As indicated in chapter three, all messages have the same general format, 
consisting of origin identification, transmission counter, message type, and 
data fields. The host is identified by a "1". in the origin field and the 
terminal is identified by a "0". The data field contains information spec ific 


to a given message type and the message type field classifies the message as a 


(1) In particular, relative field widths do not imply actual size 
relationships among fields. 
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.data (DATA), status (STA), request for status (RFS), key change (KCl & KC2), 
attention (ATT), or data mark (DMK) message. 


trans. : 
name origin counter type data field 


me ae 


ATT 


KCl 


ae laa : a ist half of new key | 


Figure 7-1 


Message Formats 


Data messages are used to transmit the character strings that represent 
explicit user-computation correspondence, including the text of high priority 


messages. The tranemission counter of the sender forms DATA.Tc.. In the type 


O*-ts 29. at . - . : Serer or oe 
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field. To prevent confusion, type field values for the other sis ednanies: 
types are numbers bigger than the character capacity of a data’ message. 
Several data messages may be needed to transmit a user level logical unit of 
correspondence. Because the number of characters contained in the data field 
is indicated in DATA.CC, no special conventions are eamasred 2 for indicating 
the end of the used portion of the data field. 

The authentication tag of a status message contains the game information as 
in a data message, while the type field identifies the mesgage as av status . 
message. STA.Re . in the data field contains the valie of tha regular wedeace. 
reception counter of the see and STA.Ac contains the value of the attention 
message counter from the sender’s end of the connection. 

The content of a request for status message differs from that of Nearer 
message only in the type field. 

In a data mark message, the standard transmission counter (DMK.Tc) field 
is used but the origin is always "0", indicating the! terminal as naadees The 
data field contains the value of the terainal.a. attention message cresaetssion 
counter in DMK.Ac. 

In an attention message, the origin is always "0", the transmission 
counter (ATT.Ac) field contains the value of the terminal’s attention message 
transmission counter and tiie. ‘data field is not used. 

Two types are used for key-changes. The origin field is always "1", 
indicating the host as sender, and the transmiséion counter field contains 
some constant value agreed upon by both ends of the connection, ¢.g., "oo". 
The data field contains half of the new key (KCx.Key), the first half arriving 


in the first key-change message and the second half in the second. 


Page 82 Preteetion Module Structure. 
Control Structure of the Modules 


Although there are many ye the modules can be: iawed ond implemented, 
we have chosen to describe each module as a Patiegler ‘process, using message 
style inderprodese communication: facilities for ‘the. interfaces ‘to “the 
Ceenidats the user process in the Agat: ana oh ‘communication: ajacea ‘An 
actual imsiecuteetian a use multinis nrocauees iGad/or pesconacre toe each 
module. We have not described a multi-process(or) implementation of the 
modules 30 ebat we may omit the details of avoiding contention Bees the | 
counters ‘Te, Re, and Ac that ‘eouid result po asyachronous pcoceceia’ of 
messages on she three channels of a. SGhneselons: = 

Each protmeeinn module can be viewed an consiecing of three operating 
states: the normal state, the bad- message state, ‘atid’ ‘the key-ch ange state. 
(2) The normal and bad-message state are nyecy similar in a both mudures: tle 
the ke y~change state is ‘module specific. | _ - e 

Two functions are used frequently by both modules: Seusage packaging anat 
error. logging. meensce packaging consieve: ‘of “Anerenenting the message 
‘transmission counter, combining this counter . value tand the origin 
identification bit to form the tag, append ing the message. 2 field and data 
field of the message, then encipher ing the ‘completed message blocks , A 
packaged message is ready for transmission on an outbound channel. The data 
field and the type field of the message are ‘eapplied to the part of the module 
that pac kages the message. In the case of che cerainal acisie. chore is also 


an indication of whether the attention or regular message counter is to be 


(2) ‘The terminal module also contains a transient. starting state, the. karma 
state. go3 
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used and, implicitly, whether to use the regular or attention channel for 
transmission et the message. 

Error ieaniat is an ae dependent function. At the host, 
Logging can be accom tenet by recording error messages ina file associated 
with each connection. At the ¢ terminal, _Logsing my be accomplished by 
generating messages on the terminal display or through Lights, audible alaras, 
etc. 7 

The structure of the two protection modules _ quite teenie We conaly, 
describe the terminal module first and then describe ee host nodule .by noting 
how it differs from the terminal module. . 

In the normal state, the terminal module is blocked waiting for both 
cleartext and ciphertext input. In the bad-message state, entered after the 
receipt of an unauthenticatable message and subsequent tranmiseion of an RFS, 
and in the key-change state the module ie waiting for ciphertext Anput only. 
(3) - _ 

We first describe the processing of ciphertext: input by the fornia’ 
module, examining the transitions pervect ‘the states and the processing chat 
occurs upon receipt of various mesaage types. Figure 12 illustrates the 
control structure of the terminal nodule in terms of Ane chr es. states listed 
above and should be examined while mending, the following discussion. 

After tranenitting his login sdentt tier in cheat tarts the user inserts 
his primary key and Snepree. the protection 1 module. me terminal module is 


g 


‘initialized by loading the primary Key. as the current key ang setting all 


(3) In these two states, keyboard input ie not “processed. ‘This may be 
accomplished by providing a buffer for input typed Wile’ the’ moduke ts in one 
of these two states, or by "locking" the keyboard. 
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three of its counters to zero. (4) The module then enters the key-wait states 
waiting for the arrival of a ciphertext block cdutsinies a valid KCl message. 
All other input is discarded until such a message arrives. Upon receipt of a 
KCl message, KCl.Key is saved and the module enters the key-change state. 

Upon entering the key-change state, the module waits for a message from 
the connection. The next message received on the connection must be a valid 
KC2 message or: the protection module abandons ‘the connection, logging the 
error, If the next message to arrive is a valid RC? message, the saved value 
of KCl.Key is combined with KC2.Key to form the new current key and Ac, ITc,. 
and Re are all set to zero. The » module packages ‘and transmits an STA message, 
logs the key-change, and returns to the normal state. . 

Upon receipt of a message on the user-computation connection in the 
normal state, the origin bit is chet hed and,.if it does not indicate the host 
as sender, the message is considered unayit henticatable. “The tranemission 
counter field and the message type field are checked and, in the case of a 
DATA or RFS message, the tranamission counter field sist’ match the value of Rc 
to be accepted. An STA message is accepted if STA.Tc bukche’ Re or if STA.Rc 
matches Tc. A KCl] message is accepted if KCI. te contains the appropriate 
constant value, e€.g.) No, | All other messages. are classified as 


unauthenticatable. Now we explore the processing of each message type. 


(4) To facilitate the pdescnipeion of the protection modules, the regular 


message tranamission counter for each channel ig designated Te and the regular 
message reception counter is Rc. The attention message counter at each end of 
the channel is referred to as Ac. 
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Sega key loaded — 
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. Key-Change State.. > 
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Figure 7-2 
- Terminal Protection Module Controt- Structure 
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A DATA message is processed by Temov ing the number of characters 
indicated by DATA.CC and forwarding them to the terminal. Re is ing¢remented 
and the module enters the normal state. | . 

An RFS measage requires logging any errors on the connection, as indicated 
by differences between the pairs (RFS.Ac, Ac) and (RFS.Rc, Tc). Then Ac is 
set to the maximum of Ac and RFS.Ac, and Rec is set to one greater than the 
max imum of Re and RFS.Tc. The data field of a responding STA message is 
constructed using Ac and Tc and the message is packaged and tranamitted. The 
module then returns to the normal state. 

Receipt of “ STA message aleo requires logging _ any connection errors. 
indicated by differences between the pairs (STA. Ac, Ac) and (STA.Tc, Re). 
Then Ac is set to the maximum of Ac and STA.Ac and Te is set to the maximum of 
Rc and STA.Tc. The module then cekuene to the normal state. 

At the terminal, when a KCl message is received, KC1.Key (the first half 
of the new key) is saved in a temporary location and the module enters the 
key-change state. 

When a bad (unauthenticatable) message is received in the ‘normal state, 
the module constructs an RFS message, us{ag the values of Rc and Ac, and 
packages and transmits the RFS. The error is logged and, if the bad message 


is a DATA message, the module forwards the characters in the data field to the 


terminal. (5) The module now enters the bad-megsage state, 


(5) In order to avoid flooding the terminal with warning messages when one of 
a series of message from the fost ts lost or garbled, fhe module could preface 
the collection of unauthenticatable mesdages ‘with a dultable warning. It. 
could then process subsequent “bad” messages without issuing further warnings 
as long as the arriving messages are otherwise "good" data messages that have 
authenticator values that are consistent with the first unauthenticatable 
message received. When resynclronization is effected, another message would 
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Upon entry into the bad-message state, the module awaits input from the 
connection. Arriving ciphertext input is deciphered and analyzed as in the 
normal state. If the input is valid, it is processed as in the normal state 
and after the processing is complete the module returns to the normal state. 
Receipt of an unauthenticatable message in the bad-message state results in 
logging of the error and a return to the bad-message state. 

Now we have completed the description of ciphertext proceuning by the 
terminal protection module and we turn to cleartext processing. In order to 
simplify this discussion, cleartext input to the module is assumed to charac 
of the data field and character count for constructing a DATA message. The 
interface presented is simpler than if we assumed character-at-a-time input 
and had to make provision for a separate signal indicating the end of a 
logical wit of correspondence. Whenever cleartext input is received, the 
character count and data are combined and packaged into a DATA message and 
transmitted. The module then returns to the normal state. 

The protection module can also receive . control signal from the terminal 
keyboard indicating that a high priority seaunae is to be sent. (6) Then an 
attention message is constructed with an empty data Field, packaged and 
transmitted on the attention channel. A data mark message is constructed with 


be issued by the module telling the user that the "window o "bad" messages 


has ended, thus bracketing the "bad" messages for the user. Although this 
feature is not included in the terminal protection as described in Figure 7-2, 
it could be included with only minor additions-to the module. 


(6) The terminal~to-protection module interface we have assumed assures us 
that previously entered regular keyboard input has already been packaged and 
transmitted before this control signal is received. Although this precludes 
the transmission of a high priority message. while the terminal is in the 
bad-message state, this is not considered to bea problem, ap it may. not be 
desirable to send a high priority message. until, the connection has been 
resynchronized. 


% 


Page 88 . Protection Module Structure 
ee > * EY Oy Ging Bac? ee Se aed 


the value of Ac as DMK.Ac and is packaged and tranemitted on the regular 
terminal-to-host channel. The module now returns to the normal state. 

Finally, we note that ‘the interface. to the terminal could provide the 
ability for a user to force couttructions “pachoatia. ‘and “transmission of an 
RFS message while in the normal state. After the. RFS message was sent, the 
module would return to the normal state. This feature is not illustrated in 
Figure 7-2. | 

Now we turn our attention 46 the host protection aodules which we 
describe in terms of its differences with the terminal module. The 
differences result from the fact that the ‘host is the sender (rather than the 
erent of Savcchanee messages, the vetaivae (cathae than one sender) of 
attention and data mark messages, and because of the use of timeouts at the 
host. In order to simplify this description, we assume that the host module 
always receives a ‘ciphertext Hicck dean its arrival at the host end of the 
connection (see chapter six), without having to wit) for a request from the 
user computation for more Anput. (7) - We. alec ‘assume ghia there is no 
buffering between eh: host protection module- éad the connection management 
module (CMM), so that it is not necessary to notify the connection management 
module upon receipt of a data mark message nor.is it necessary to éranetann 
the data mark message into a reserved character. AS an aid in following the 


discussion that follows, refer to Figure 7-3. 


(7) This corresponds to a communication system organization in which no 
buffering of input from the connection occurs before processing by the host 
protection madule (see chapter six). 
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Figure 7-3. 
Host Protection Module Contyol Structure 
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In the normal state, the host module is blocked waiting for cleartext and_ 
ciphertext input and a timeout. In the key-change and bad-message states, the 
module is blocked waiting for signer tax’ input and a. timeout. 

There are two types of timeouts used by the host module, although only 
one is pending at any instant. (8) The. first type, an.integrity check 
timeout, is used to periodically trigger a. connection - dategrity check. The 
second type, an STA. timeout, is used when .the module is waiting for an STA 
message on the connection. 

Message authentication by the host module is very similar to 
' authentication. carried out by the terminal medule.. Only messages with an 
origin bit indicating the terminal. as sender. are analyzed further. . The 
aunt ewes authentication criteria at. the. host. “are ‘the game as at the 
terminal for DATA, RFS, and STA -mesgages. . DMK messages are accepted under the | 
same criteria as DATA and RFS messages. ATT. measages are authenticated based 
on the value of Ac. . . | 

The host module is initialized, after the cleartext login identifier has 
been received, by loading the primary key, retrieved froma host data base, as 
the current key and entering the key~change state. 

In the key-change state, the protection module generates a secondary key 
and constructs two key-change messages, each coutaining half of this new key 
in its data field. The KCl and KC2 messages are packaged and tranmitted in. 


order. The module changes the current, key to ba .the secondary key just sent 


(8) Timeouts are modeled in the control structure through the . use of “two: 
primitive operations: establishing,...a timeout. and. cancelling a timeout.. 


- Establishing a timeout. involves specifying. .an elapsed time. interval after 


which the timeout wakeup should occur. A timeout that is cancelled will never 
generate a wakeup. . Posh ae -. ae eee 
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to the terminal, resets Tc, Re, and Ac to zero, and logs the start of the 
login session for this conneetion. The module establishes an STA timeout and 
_awaits this timeout and input from the connéetiist. The module is waiting for 
a valid STA message, discarding all other ciphertext input. If the STA 
timeout occurs before a message arrives on the connection, the module abandons 
the connection and logs the error. When a valid STA message arrives, the 
module processes it, cancels the STA timeout, establishes an integrity check 
timeout, and enters the normal state. (9) 

Upon receipt’ of a DATA message, the host module performs the same 
processing as the terminal module, in this case forwarding the characters to 
the user computation via the connection management module. | 

Receipt of an RFS message results in the same counter adjustment, error 
logging, and transmission of an STA as performed at the terminal. 

Receipt of an STA message results in the same counter adjustment and 
error logging as performed by the terminal module. The pending STA timeout is 
cancelled and an integrity check timeout is established. 

When an ATT message is received, the exact form of processing its system 
specific, as noted in chapters five and six. As we are assuming an 
environment in which ciphertext messages are ‘forwarded to the protection 
module upon arrival at the host, the module just logs arrival at the host of 
the ATT message and returns to the normal state, awaiting the DMK message. If 


an intervening buffer were present, interaction with the commumication system 


(9) The host protection module can maintain the total number of times the 
key-change protocol has been invoked ‘and compare® this value to a 
user~specifiable limit. If the limit ‘1s exceeded, the module will abandon the 
connection and log the error. This provides the user with a means of 
eontrolling the amount of resources expended in resynchronization efforts. 
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might be necessary to cause input buffered before the geieae ica module to be 
forwarded to the module, in order to search for;the DMK. . | 

When a DMK message is received, DMK.Ac is compared with the host value of 
Ac. to determine if there are any attention weieages unaccounted for. If a 
buffer were present between the protection module. and the CMM, a data mark 
character would be inserted into that buffer, the count of data mark messages 
received would be incremented, and a signal would be. sent to the CMM. In any 
case, if there are no attention messages unaccownted for, the module returns 


to the normal state. If one or more attention messages are missing, an RFS 


“message is constructed, packaged, and. tranemitted and an STA timeout is 


established. 

When an tategrity check timeout occurs, the module constructs, packages, 
and tranegmits an RFS message and establishes an STA timeout. This timeout 
will be cancelled only by receipt of a. valid STA measage or. upon .entry. into 


the bad-message state. The module returns to the normal state. When.a STA 


timeout occurs, the module enters the key-change state. If an intervening 


buffer were present, it would first be necessary to ascertain that the STA 
message was not in that buffer before the transfer to.the key-change state was 
effected, 


Upon receipt of an unauthenticatable message in the normal state, the 


module logs the error, constructs, packages, and. trangaits an. RFS message. 


The integrity check timeout is cancelled and an STA. timeout is established. 


The module now enters the bad-message state. 


Once in the. bad-message state, the madule waits only for ciphertext input 


and the STA timeout. Receipt of additional bad-messages results in logging of 
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their arrival, but no idaieiesat RFS messages are transmitted. (10) Receipt 
of ; valid DATA, RFS, art, or DMR me ssage results in processing Just as in the. 
normal state, but the module remains in the bad-message state. “Only receipt 
of an STA message will cancel an STA timeout, establish an id tegrtty check * 
timeout and return the ‘modtile to the ‘normal state diréetly., ff the STA 
timeout occurs, then the module enters the ‘key-éhange’ state. 

_ Processing of cleartext input*by the host ‘module parallels: that of ‘the 
terminal module and is simplified by the lack of ‘the high priority mes sage 


signal. 


Summary 


This chapter presented the formats of the:severl message types used to 
implement the protection pfotocdls /:dusct ited ie @arlier cha ptexs, All of 
these messages share a commion fotwiat that permits easy {dentification and: 
authentication through standard location of thé authenticator atid message type 
fields in the message block. The conttol ‘structure of ‘the ‘host and terminal 
protection modules is presented. 

The host module is more complex that the terminal” nodule, incorporating 
mechanisms for automatic detection of connection blockage, initiating 
key~change procedures, and assuming final reapénetbiifty for: resynchronization 
efforts, reflecting the greater computational power avdtlable* ‘at ‘the host. 


- Provision is made for the user to exert fafluence evér the ‘reaction of the 


(10) The host module can maintain totals: on’ the ‘ftumbér’ of bad messages 
received and the number of consecutive bad messages received and effect a key 
change or abandon the coniiecttén if ¢thése totals exceed “tser-définable limits. 
This provides another means of permitting the user to exercise influence over 
the amount of resources spent in attempting to resynchronize the connection. 
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protection modules to possible intruder threats or extreme channel error 
conditions, preventing excessive resource commitment to resynchronization and 


recovery attempts. 


Chapter Eight 
Implementation on Multics 


This chapter describes the structure and operation of a test 
implementation of the protection protocols on the Multics system and explains 
some of the considerations involved in designing an implementation that could 
be incorporated into a production Multics system. The test implementation was 
undertaken to test the completeness of the proposed design and és evaluate the 
impact of ‘the. protection protocols upon the human interface of a computer 


utility. 
Structure of the Test Implementation 


As illustrated in Figure 8-1, the test implementation uses four distinct 
processes on the Multics system [MIT] to simulate a user controlling a 
computation through a connection peeeacted by the modules developed in this 
thesis. Each process communicates with adjacent processes by means of ARPANET 
connections [RW]. 

One process simulates the functionality of the terminal protection 
module, andtiny wieeveese and ciphertext input as described in chapter seven. 
This process is created by logging in from any terminal and invoking the 
terminal module sinuieeien program. It reads input from the terminal through 
standard Multics input facilities. In order to more accurately simulate 


transmission loads, erase-kill processing and canonicalization are not 
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performed on the input stream from the terminal to this module. Instead, such 
operations are performed at the target process. When echoing is eaigloyed. the 
echo processing is performed on the input stream from the terminal to the 
terminal module process, ‘saictating the style of remote controlled transmission 
echoing described in chapter six. | 


ARPANET ARPANET ARPANET 
Connection Connection Connection 


{ 


"[-—----->] Target 
<ame---—f{ Process 


Module 
Process 


Process 


<--dialup lines-=> 
User _ Intruder | - 
Terminal |} Terminal 


Figure 8-1 
Configuration of the Test. Implementation ‘on Multics 


A eo ttidn handles is established in tis teen inal: module process for the 
"quit" condition, the only high oi its weasace técognized by Multics. Upon 
ae of a quit from the . terminal, this eucwas transmits a data mark 
message on the regular terminal-to-host channak No separate attention 
channel is employed. There is no need to tranemit an attention message, as 
there are no demand buffers in the ARPANET connection becuad the terminal 
module process and the host module process. 

The intruder computer in the connection is simulated by a process 
aituated between the terminal and host protection module processes. all 


message traffic between the two ends of the connection passes through the 
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intruder process. This process is created by logging in from any terminal and 
invoking the intruder computer simulation program. The intruder process has 
the responsibility of logging in the host module process over the ARPANET and” 
initiating the execution of the program that simulates the host module 
functions within that process. The intruder also acts as the initiator of the 
ARPANET connection between itself and the terminal module pracess. 

Several commands are provided for the intruder (the person at the 
intruder terminal) to engage in Gag isae ‘foras .of connection disruption. 
Provision te: made for the intruder von venave message lacks traveling in 
either direction over the eons The intruder can cause a selected 
message to be copied from the connection and inserted into the connection at 
any future time. Spurious message blocks can ‘be generated and inserted tito 
“the connection at any time. Message blocks from either end of the Spaneceaon 
can be rerouted to their sender. The intruder can monitor the traffic on the 
connection in one or both directions selectively. All of the operations noted 
above, with the exception of the copy operation, can be performed on one or 
more message blocks as specified by the intruder i che écanaad. C) 

The host — protection module process ianlemente the control structure 
described in chapter seven and maintains a log of important events that occur 
- the cipher connection. The protection nGdule log can be examined during or 


after a login session to review abnormal channel activities.as observed by the 


(1) Note that the intruder does not posess.any commands,.that enable him to 
engage in actual cryptanalysis of the message traffic he observes. It is felt 
that the analysis presented in the appendix. indieates-that such actions are 
not practically performed in real time during the login session. Moreover, 
adequate facilities for such cryptanalysis are not available to the. author for 
inclusion in the test implementation, : 
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host. This process creates the target procesg, logging it in via an ARPANET 
_connection, at the beginning of a_ test segsion. _ The host module process 
receives output from and forwards input to the target process via this ARPANET 
connection. . Upon receipt of a valid data mark message, the host module 
process sends a quit to the target process, using thie ARPANET connection. 

The target process is a regular Multics pracess in which the user of the 
test implementation may per form computations just as with any process logged 
in directly from a remote terminal. The target process acts as though it were 
attached to a user terminal over the ARPANET, in terms of terminal-specific 
input / out put transformations. It is in the input stream to this process that 
the functions of erase-kill processing and canonicalization .are finally 
- performed. 

The login protocol described in chapter three is not implemented. After 
logging the terminal and intruder processes into Multics in the usual fashion 
and initiating the execution of the appropriate simulation program in each 
process, the terminal user merely responds to a query to begin. ‘ie session. 
The first output on his terminal after this is the login greeting from the 
target process logged in for him. . 

_ The problem of Loading the primary key into the protection modules at 
both ends of the connection is handled by. maintaining a key in a shared 
segment that both the terminal and host module. processes access. This segment 
does not serve ag a communication vehicle between the two processes in the 
sense of any of the functions that are associated with the module control 


structure. 
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The programs for the test implementation were coded in PL/I, with the 
‘exception of the encryption algorithm, which was coded “in assembly language in 
order to take advantage df ‘bit manipulation instructions not accessible from 
PL/T. 128-bit blocks were used and were enciphered using a software version 
of IBM's Lucifer algorithm [Ben] that {#‘avaflable on Multics. ‘this softwaré 
implementation éan encipher/decipher a block in “approximately four 
milliseconds. 

A twenty-four bit authenticator is employed in the messages, along with a 
six-bit message type field. ‘This permite the tradsm{ssion of from one to 
messages are the most frequently transm{tted messages, the authenticator size 


was chosen to result in a:full block for this message type. 
Results oad, Hat os oi a 3B a ee 


The implementation was tested on several occasions with a human - 
controlling the process that simulated the intruder computer . A variety of 
attacks on the connection were attempted, ‘including message rerouting, message 
deletion, generation of spurious messages, and insertion ‘of copies of old 
messages. These attacks were carried out “with complete ‘knowledge of the 
operation of both the terminal and’ host modules so that very specific types of 
message stream modification were effected, e.g., deletion of a request for 
Btatus or statis message duting connection resynchronization. The protocols 
performed as expected, detectirig each act of tiessage stream modification or 
denial of service, reporting these acts to the user and the host, and 


restoring normal communication on the connection if possible. 
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The impression given to a user of the test iagi enentacion must . be 
tempered by several considerations. The delays that tend. to: degrade the 
response time to commands iasued by the user: are a result. of. several factors, 
most importantly the seven process. schedulings ‘required - by a complete 
roundtrip interaction. ‘The fact that process scheduling is the most important 
factor in the perceivable delay is evidenced by variations in the delay. under 
different system loads. 

During extended periods of input, e.g., while entering text into an 
editor, or while executing commands that usuakly have ‘noticeable: dalays. 
associated with them (the PL/I compiler) no apparent differences in response 
time are observed. Similarly, while ispatig comands” chat “tend to ‘deliver 
large amounts of output to the terminal, the user of .the test implementation 
is not generally aware of the intermediate: procesaing going , on between his 
terminal and his target process. This is especially true if the user ts 
‘typing ahead, through his output, so that the response delay: can be hidden by 
the continuing output from previous ites race tien Characteristic of the 
performance of the test implementation under Light’: upetes loads (30 users) is 
the fact that it is able to drive a 1200 bps termine): at capacity dur ing 
output from the host, although it could mot drive a 2400:: bps . terminal 
similarly. | | 

User experience with the test implementation. led» to “the idea of 
"bracketing" a series of messages. from the host that arvive after the lose or 
destruction of an earlier -host..message. in the-serias, rather that repeating an 
error message with each successive, unauthenticatable host message. It has 


also been suggested that some means of "replaying" to the ueer the last good 
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message (or messages) received should be provided so that he‘can resume input 
‘from a known place, after disruption of the cénhection. This feature is 
easily added to the host module software. ‘In a similar vein, is might be 
desirable for the host module to fotward’to the terminal the error messages 
that are being placed in the host etpiier log, on a user<controlled, selective 
basis. | 

Overall, the performance of the protocols in this test implementation 
suggests that, if a suitably fast implementation were used, the impact on the 


human. interface of a computer utility should be negligible. 
Considerations for a Production Implementation | 


We now examine how a production version of the host protection module 
might be incorporated into the Multics system. The discussion is meant to 
provide some indication of the ‘considerations involved in 4° production 
implementation of the protocols in an existing system and should not be 
construed as a model for all systems, as Multics does not exhib#t all ‘of ‘the 
potential complexity pessible in a host communication system. 

The description of the internal organization of portions of Multics, as 
presented below, has been simplified in some places where the loss of detail 
was felt to be irrelevant to this discussion. The description of the 
structure of the input/output system reflects ongoing ~- and planned 
modifications to the Maltics Communication ‘System. *: 

Multics employs. a front end processor. as an interface «for dialup | 
commun ication lines (but not for. the ARPANES) »: -This: front:end procéssor is 


not considered secure, implements only very primitive supervisor facilities 
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and is programmable only in an assembly level language. It is a multiplexed 
communication facility, as described in chapter six, and it communicates with 
- the central ncceeawis via a direct memory interface. 

The front end processor buffers terminal input and forwards this input 
to the central processor upon receipt of a newline character. Thus, it 
engages in recognition of the newline ag a break character. Multics is 
accessed primarily by asynchronous terminals, and multi-character substitution 
echoing is performed by the front end processor if requested. Finally, high 
priority messages in the form of "line breaks" on asynchronous lines are 
recognized by the front end processor as “quite”, causing it. to discard any: 
input or output buffers it holds for the aignall ing line and to notify the 
central processor of receipt of this high priority message. 

In the central processor, two levels .of input/output procegsing are 
involved: the supervisor level and the user level, At the supervisor level in. 
Multics, input from the front end processor is copied into multiplexed 
core-resident buffers and then. into private buffer. areas for each. user. 
Output from user processes is copied into core-resident buffers and 
transferred to the front end processor, Thus, at the supervisor. level, only 
buffer management is per formed. At the user level in the central. processor, | 
the transformation operations noted earlier for input (translation, 
canonicalization, erase-kill processing, and escape sequence atocawsies) and 
output (translation and formatting) are implemented. 

Multics also performs input and output to..remote terminals via an 
interface to the ARPANET. This ARPANET intarEacs doas not involve the front 


end processor, but appears to the central processor as a peripheral device. 
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The software structure of this interfacé involves three major Tevels of 
processing. At the lowest level is the module that’ acta: ae the device handler 
for the ARPANET IMP to which Multics is connected. ‘This module is interrupt 
driven and operates in the supervisor, implementing the host-IMP protocol 
[BBN] of the ARPANET and managing multiplexed buffers of data for the IMP data 
- channel. Logically above the IMP interface module, but still operating in the 
supervisor, is the network control program, © which implements the ARPANET 
host-host protocol [ARP] and provides for the multiplexing of the nétwork 
interface among Multics users. ‘Finally, higher level protocols, e.g., file 
transfer, telecommmication network, and tnitial connection protocols [ARP], 
are ieplawented in each user’s process in the user level. 

Over the ARPANET, ‘attention messages are crddéuitted on a ‘separate 
logical channel and are directed to a special network piotess for handling. 
The network process, a trusted, privileged process, determines the ee 
process for which the attention message is déstined and handles it 
appropriately. It also’ monitors all of the network connections to Multics and 
handles error conditions raised at the host~IMP protocol level. . 

The memory protection facilities of Multics “provide multiple address 
spaces, each with eight linearly otdered rings of protection [Sal2, SS2]. The 
system gives each process its own address space in which the supervisor 
functions execute in the most privileged rings (0 and 1) and user procedures 
execute only in the higher rings (4-7). 

For a production implementation of the protocols ‘developed in this 


thesis, we propose that each cipher connection’be provitled with a separate 
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process to execute the host protection module. This process would reside. in 
ring two or three of the address space of the corresponding user process. (2) 

Sharing the address space with the corresponding user. process makes each 
protection module process relatively inexpensive. Executing in ring two or 
three protects each module from the user ring programs, but still provides an 
execution environment that is private for each user ae aaaee tga above the 
multiplexed buffers managed at rings zero and one, Finally, by making each 
protection module a distinct process, it can be simply programmed to manage 
only one connection, accepting each ciphertext block as it arrives without 
waiting for demands for input fied the correspond ing user process. 

The front end processor must be aware of, the connections that will be 
using the protection modules, so that it can, accept, the.encipbered input. and 
forward it to the central processor a, block at.a time. On synchronous 
communication lines this should pose no problem as entire enciphered blocks 
can be transparently transmitted dning synchronous. line..control protocols 
[ISO, IBM1]. On asynchronous lines this may require assembling character-sisze 
pieces of a ciphertext block until a complete block is formed. Some form of 
block framing may also be desired in order to inaure that entire blocks are 


forwarded to the host module, for if block frame synchrony is lost, the ~ 


(2) While the current process implementation forces each process to have its 
own address space, an implementation of processeg that would permit two or 
more processes to share an address space in this fashion has recently been 
developed by Reed [ReD]. Using the current process implementation, one can 
avoid the cost of a separate process with its own address space for each 
protection module by multiplexing a single trusted process among all cipher 
connections. However, this savings is achieved at the cost of increasing the 
complexity of this process, as it must now manage many connections at once, 
and violating the security principle of least common mechanism noted in 
chapter six. 
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connection must be manually suspended and re-established in order to resume 
conmun ication. | 

Of course echoing can no longer be performed by the front end processor 
and some substitute for this must be provided as outlined in chapter six. On 
half-duplex lines, line breaks must still be used to terminate sutpue es the 
host and turn around the line for ecteinal ape: but a quit should be sent to 
the user process only upon receipt of a valid data mark message. On 
full-duplex lines, line breaks ‘need’ uo longer be sent since attention messages 
ean be transmitted on the terminal-to-host ohankéd: ith assurance of being 
processed rapidly by the host module. 

The protection module process would accept input ciphertext blocks upon 
arrival at the central processor from the supervisor level buffer management 
software for both dialup: lines and ARPANET connections, process them as 
outlined in chapter six, and place the deciphered input into buffers foe see 
level input processing. Output from a user ‘process would be processed by this. 
module and ciphertext blocks would be forwarded to the supervisor level buffer 
eens software. 

We also propose the introduction of a hardware encryption shetrustion 
capable of enciphering/deciphering one or more 64-bit blocks using the NBS 
data encryption standard. Such an instruction would be a logical extension to 
the multiple-operand extended instruction set used for character and bit 
manipulation on Multics (Hon) .. This instruction could be used to enc ipher 


* 
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data both on communication channels and for protection of data stored on 


removable media, e685 tapes and demountable disk packs. (3) 


' Performance Considerations 


There are is aie areas of éyuveu bar tuccance that will be affected by 
use of the encryption pestaceien modules: host system overhead in supporting 
cn neotmeote and connection bandwidth ue{lieation and delay resulting from 
cheater use. Host aysten oiavneea seed vat in supporting the protocols includes 
the cihewawor and memory veisutéde raquired: to decipher and authenticate 
iiedelt he messages, to aietanes ere output, and the processing involved in 
resynchronization, Lapechadee, and denial of message service protocols. The 
vetheed for resynchronization is edcoimtared only when connection disruption 


occurs and should be considered as a marginal cost, except when such 


disruption is a major problem. The time dedicated to detection of dental of 


message service is controllable by parameters that should be user definable, 


thus permitting the cost of this protection to be controlled by the user, 


within limits established by installation parameters. 


Examination of oe control structure of the, protection module . indicates 


that most of the oat: under usual circumatances, would be spent in ‘the task 


of regular data mesenge processing <. The operations involved in this task are 


all readily _ Programmable on modern host systens, a8 _long as a hardware 


esciher ing) aeespheticg instruction is provided. The associated overhead per 


message block would be on the order of 50-100 microseconds on a large host 


(ay The details of. ‘the ‘operation of such an’ -snbledeet will vary based on. the 


architetture of the-host computer, and thé” design 3 such an. instruction is a 
topic requiring further study. 
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system, given a hardware enc ipher ing/dec ipher ing instruction capable of 
deciphering a block in 5-50 Siccasscoude: since a 64-bit block could hold 
five or six characters when used as a user data message block, this overhead 
is about 9-20 microseconds per character for full data blocks. 

Additional overhead is involved through the use of muleaple processes to 
implement the host protection module functions and Stier commuiication systen 
- functions, but a comparison betasen: this Scpanieation and the current ‘system 

Steantvatton is hard to make. Experience using aura processes to seovide 
echoing over the network indicates that the overhead involved in such 
organization is not substantial. The working ste of the processes involved 
are small and the functions provided are rather eed and execute rapidly. 
With respect to transmission bandwidth, it ie reasonable to ignore the 
effects of messages associated with cheyacteontaation.. key-change, | and 
detection of denial of message service protocols, as tnees messages should 
constitute a very small fraction of the total message traffic. The reduction 
of bandwidth over the connection is a result of dedicating a portion of each 
message block to authentication and message type information. In a 64-bit 
block, this information would occupy ongae 25% to 35% of the block. (4) Thus 
only 65% to 75% of the connection bandwidth is available for user data 
transmission. On input bandwidth utilization is usually not a problem, as the 


user rarely is capable of taking advantage of the available bandwidth. on the 


oy, 


(4) In a 64-bit block, five or six characters can be accomodated with space 
for a four~bit message type field and an Sager Silke that provides a 
“probability of erroneous authentication. on the order of 10°. The number of 
characters varies depending on character size, seven... Or. -eighe. bits. per 
character, and desired authenticator size. 
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connection. (5) On output, however, this is a disadvantage as the host. system 
. usually is capable of using the maximum channel capacity in short bursts. 

| With respect to delays, the control structure of the protection modules 
and the discussion of host system overhead in message block processing from 
above sidisates that the overhead for preparation, encryption, decryption , 
and authentication of a single message block should result in a negligible 
delay. Assuming a terminal module implemented using a microprocessor and a 
special hardware encryption chip, the total time. required to process one 
message block should be about 100 microseconds. This indicates that the speed 
of the encryption protection module is not a bandwidth limiting factor for 
data rates associated with user-computation connections. Relative to the 
other processing delays encountered by interactive terminal users in their 
communication with a host system, the delay introduced by the use of the 


protection protocols is negligible. 


Summary 


The test implementation tested the completeness of the protocols and 
permitted evaluation of the impact of the protection protocols on the human 
interface of a computer utility. The protocols performed as expected and 
generally were transparent to the user. Even in situations where the intruder 
sccieais engaged in connection disruption, the impact: on the user was 
mitigated by the automatic resynchronization protocol. “With the addition of 


further enhancements noted above, the user interface could become quite robust 


(5) If input to the host is via a multiplexed connection, e.g., an ARPANET 
connection, this reduction of bandwidth may be of contern. 
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in the face of dedicated intruder line disruption. The delays experienced in 
the test implementation were unacceptably long, but with the use of hardware 
encryption at both ends of the connection and the use of a microprocessor to 
implement the terminal protection module, it appears that the delays would 


become negligible. 


Chapter. Nine 
Conclusions 


The goal of this thesis was to develop a set of protocols to organize the 
use of encryption to provide a secure path between a ee at a terminal and 
his interactive computation in a remote host computer. We have proposed a 
set of protocols to accomplish this soil aud perio teed * first Aeionetvation 
of their feasibility. These "protocols are designed for use with a block 
cipher such as the proposed NBS Data Encryption Standard or IBM’s Lucifer, 
taking advantage of the fixed-length blocks to delimit data and control 
messages. In producing these protocols, every effort has been made to be 
complete and general. Provision is made for all coamon aspects of interactive 
user-computer communication -- from authentication at login, to high priority 
messages, to character echoing. The protocols ute deaisuee to function in a 
wide variety of communication system configurations. 

The level of description in the thea s should be sufficient to allow an 
implementation to be engineered for most existing and foreseeable systems. We 
hope that this work will contribute to future widespread use of 
encryption-based protection measures to reduce the vulnerability of computer 
systems to release and modification of the data they contain through intrusion 
on their largely unprotected communication facilities. In “ order to achieve 
are widespread use of saceeeieutaadl measures, both an encryption algorithm 
and a set of protocols must be standardized to permit development of ew cask 


terminal protection modules that can be used with any host that employs “such 
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measures. We hope that this research will stimulate work on a standard set of 


protocols. 
Future Work 


Although the level of description provided in this thesis should be 
adequate for one attempting to engineer a terminal protection module, there 
are areas deserving of further study with respect to implementation of this 
module. It appears that the use of a general purpose microprocessor and a 
special purpose encryption chip should provide an adequate hardware base for 
the terminal nodule, but questions remain as to _what other functions 
could/should be taken on by the microprocessor, e.g., remote controlled 
echoing and communication line interfacing. There is also the question of 
unite different at raneceane of one or more NBS encryption chips to provide a 
wore secure cipher scheme. Hellman and Diffie have speculated [DHl] that a 
cipher constructed by cascading two NBS encryption chips and using independent 
keys would be more secure than the use of a single NBS chip. Such a 
modification to the protection modules is. easily accomplished within the 
context of the protocols employed in this thesis. It would be a simple matter 
to extend the key-change protocol to use four measages to transmit the keys 
for the two cipher chips. 
| Another topic ee future study lies in, the development of production 
versions of the host protection module. The protocols have been designed so 
that the host aodute can be implemented in existing systems using the wide 
variety of host communication system configurations that may be encountered, 


although the task of implementing the host module probably will vary in 
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difficulty from one howe to the next. ‘The amie ‘form see the host 
encryption/decryption instructions ana ig problem of managing the primary 
keys at the hoat both require Saretul atudy: Another ImpOFeane consideration 
in host implementations will be the overhead encountered by che. peek: and shee 
delays introduced into user interactions. Bapirical analysie of the cost of 
supporting the me ee modules and measurement of their performance -snould 


be conducted. In a similar vein, studies of the psychological impact of wing 


the pEotocole. should be carried out to determine how human inter face could 


be further improved. 


. It : would be eacouceeine to see a proof of correctness of an 
implementation of the protection protocols developed in this thede: The area 
of Logical verification of protocols has received Little pe. far 
[Boc] , but will ‘certainly be critical to the acceptance of the seatscois: a8 
the eonscbuation of secure systems, Part of the difficulty ‘of proving tha 
correct operation of the protocols lies in establishing the formal assumptions 
that correspond to informal goals. | 


There is. need to develop suitable algorithms for generating primary and 


secondary keys at the host. Algorithms used for this purpose should have the 


properties that the keys they generate are statistically well distributed yet 


the sequence of keys should not be predictable by someone observing successive 


members of the sequence and knowing the algorithm being employed. Certainly 


much research into this area must have been performed by agencies of the 
Department of Defense in conjunction with existing needs to generate keys, but 
it seems unlikely that many of the results of this research will become 


publicly available, In the public domain, Hellman [Hel] has suggested the use 
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of two random number generators, one generating statistically random numbers 
using a conventional technique, as described by Knuth, ena the “othe: 
gederating “ngabacs 45 a "non-deterministic"” fashion, @ Bey deine the value of - 
the real time clock as part of its functional input. Encryption keys could be 
fashioned by combining the output from cigbe. two edited nuaber generators 
salae an exclusive-or operation. | | | 

Finally, it ioaia Ge ves interesting to see if similar protocols can be 
devel oped based on aeons ciphers. The use of stream er neee holds the 
promise of overcoming bandwidth utilization problems by euploying 
variable-length messages. However, it is not clear whether protection modules 
and protocols developed for use with strean siecs Kanibe as nintie “as the 
ones illustrated in this thesis. the tradeoffs becwsen bandwidth utilization 


and complexity must be carefully examined. 


Appendix 


Cryptanalysis 


The conversion of ciphertext to cleartext by analytic techniques without 
knowledge of the key is a topic beyond the scope of this thesis. As noted in 
chapter two, it is assumed that both Lucifer and. the NBS. algorithm are 
resistant to such cryptanalytic attacks. (1) In the case of the NBS 
algorithm, as noted by Diffie and Hellman [DH1}, the potential availability of 
very fast, inexpensive encryption chips, and the size of the key space for'the 
NBS algorithm make breaking the cipher by exhaustive searching of the key 
space not entirely ieteneibie. It is drenic- that the potential availability 
of an NBS encryption chip may make practical both the inclusion of encryption 
'. devices in terminals and the breaking of the cipher system by means formerly 
considered impractical. As the possibility of practical exhaustive search is 


of importance in assessing the level of security. provided by encryption, we 


(1) It is very hard to establish the resistance level of an encryption 
algorithm to cryptanalyais. If a method of analyzing the cipher is discovered 
then it provides an upper bound on the amount of work that may be needed to 
break the cipher. But.if no method is found, then one has: no guarantee that 
the cipher is unbreakable or even very hard to break, since some fresh 
analysis might discover a simple means of drastically reducing the work needed 
-to break the cipher. Whenever the cipher in question is not theoretically 
secure, one is faced with this problem. During the development of Lucifer, 
IBM made efforts to determine how susceptible the cipher was to various 
cryptagglytic techniqes. Although these efforts did not reveal any 
weaknesses that could be exploited by a cryptanalyst, this does not provide 
one with a firm basis. for concluding that the cipher is practically 
unbreakable. 
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now present an analysis of the effort required to break the NBS and Lucifer 
ciphers by key space search. 

The goal of an exhaustive key search is to determine the key used to 
encipher some set of message blocks. It is presumed that the analyst has 
available some number of blocks of ciphertext and that for some of these 
blocks he knows portions of the corresponding cleartext block. The key samcek 
is to be performed by a large system equipped with an array of computing 
elements, each capable. of deciphering (or ene ipher ing) a single block of text 
and comparing the result (with masking) to another block in parallel. Each 
element in the array can signal the result of a successful operation to a 
. central controller. We will refer to the amount of time required to perform a 
single deciphering and comparison as the basic cycle time of this system. 

A single element could be used to search the entire key space. By 
employing large numbers of the elements all operating in perailel under the 
supervision of some central unit, Sears. the amount of time required to 
search the key space can be reduced by a factor equal to the number of 
elements employed. 

Now that we have a model for the key search process, some discussion of. 
the size of the key space and the expected duration of the search is possible. 
For the 128-bit Lucifer, the key space conte ids: approxiadtely 3.4 x 1078 keys ,, 
while the NBS algorithm, using a 56-bit key, has a key Space containing only 
approximately 7.2 x 1016 keys. Note that, on the average, only half of the 
key space need be. searched if the correct key canbe recognized when 
encountered. The conditions Sunder diich an Anelivat Sees know he has the 


correct: key will be discussed later. 
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We will now make a simplifying assumption about the nature of the cipher 
that is being analyzed. the assumption is that the cipher is approximately 
perfect. A perfect cipher has the property that no two distinct keys. will 
transform two distinct cleartext blocks into the same ciphertext block [Sha]. 
(2) Although Lucifer and the NBS algorithn are not necessarily perfect, it is 
believed that they. probably do not deviate significantly from, this property 
[FH3]. In the case | of a perfect ‘cipher, an analyst who possesses one 
ciphertext block and the complete. matching cleartext can aow determine, by 
exhaustive searching of the key space, which key was used to encipher the 
block, because only one key will transform a specific cleartext block into a 
specific ciphertext block. Tf. an analyst knows. all but & bits of the 
cleartext in an intercepted ciphertext bleck,. there are. ak -Aeeys that will 
correctly decipher the know portion of the block while..the.unknewn bits range 
over all the possible values that k bits may take on. 

When an analyst has several blocks and portions of the cleartext 
associated with each, it is reasonable to.ask how many keys will be in the set 
that results from intersecting the results of the key searches.for each of the 
incompletely known blocks. Let K be the size of the. key space, N be the 
number of unknown bits in each intercepted block, and J be the aumber of such 
intercepted blocks. Then the expected size of the set that results from the 
intersection of the "possible" key sets for each intercepted block, B(I), is 


given by the following expression. 


(2) For purposes of exhaustive key searching, " perfection" constitutes a worst 
case assumption. In the case of a nonmperfect cipher, an intruder may 
discover several keys. that correctly decipher a known intercepted block of- 
ciphertext and he must further test to determine which one is the key used to. 
encipher the collection of messages in which he is interested. 
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ey ee SE 
E(I) = (K-1) * (2-1) +1 


The meaning of this result is that the possession of only a few blocks and the 
knowledge of ee modest fraction of the bits in each block reduces the 
ed jectal ‘pite of the intersection key set to léss than two. In the case of 
the NBS algorithm, with ofly two intercepted blocks and 36 bits known in each 
block (56% of the block) an analyst can discover the key used to encipher the 
blocks in a two-phase operation. All but a few of the array elements can be 
put to work simultaneously deciphering one of the two blécks with a number of 
different keys. Whenever one of the elements find&’ a key that’ correctly 
deciphers the know portion of the first block, oné of the otherwise idle 
elements will decipher the second block with “the “same key. Despite the 
incomplete information available to the analyst, this procedure will usually 
produce only one key that correctly deciphers’”the~ known portions of both 
blocks. . 

Despite the arguments presented above, there is still an overriding 
question dias has not been considered: How long will it take to search the 
key space? “We have noted that the time involved in’ the key space search is 
inversely sréporconal to the number of elements in the array; adding more 
elements reduces the time required to ‘perférd the search. Let us examine a 

concrete example to put the question into perspective. 
| Diffie and Hellman have proposed a scenario in which a decipher ing device 
similar to the one described above is constructed {DHi}+. They suggest that 
the special purpose chips can be made with a cycle tine of one wicrosecond at 


a cost of about $10 per chip, and they propose the construction of an array of 
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1,000,000 chips and associated eontroliing and power supply hardware, costing 
again as much as the seas of gpecial ‘purpose chips, for a total asatea cost 
of $20,000,000. They point out that such a systen could search half the key 
space of the scopesed NBS algorithm in about one day, given a matching clear 
and ciphertext block. on the other hand, the time required for a similar 
‘search of the key space of the Lucifer algorithm is about 10/9 years. 

Our earlier results on exhaustive searching of the key space given only 
partial matching blocks of clear and ciphertext indicate that more time would 
be required e5¢ successfully determine tiie key ala such circumstances, but 
‘the extra time involved should not be substantial enough to change the general 
nature of figures put forth by Diffie and Hellman. 
| Thus, while it is not feasible to consider exhaustive key searching as a 
means of discovering the key used in a Lucifer based system, it is not 
unreasonable to consider such an attack on a aystom based on the NBS cipher. 
As Diffie and Hellman point out, these calculations aré especially disturb ing 
when the projected improvements in hardware speed and reduced hardware costs 
of the next decade are taken into consideration. Similar ealcuistions can be 
performed assuming different system cycle times, numbera of array elements and 
costs. Basically, though, it is apparent that a determined analyst with 
adequate resources can determine the key used to encipter potentially Large 
votumes of data under the NBS cipher within a reasonable time period, given 


some knowledge of the contents of intercepted ciphertext blocks. 


- Bibldography 


[ARP] Advanced Research Projects Agency, "ARPA Current Network Protocols," NIC 
7104, Network Info. Centers Stanford. Res. Inst., Menlo Park, CA., Dec. 1974. 


[Bar] Baran, P., "On Distributed Communications: Vol. IX, Security, Secrecy, 
and Tamper-Free Considerations," Rand Memo. mM-3765-PR, August 1964. 


[Ben] Benedict,G., “An Encryption Module for Multics," BSc mente, M.I.T., 
Dept. of Electrical Engineering, May .1974..,(Aleo available as M.I.T. 
Laboratory for Computer Science Tech. Memo. TM-50.) 


[Bob] Bobrow, D., et al., "TENEX, a paged time shar ing system for the PDP-10," 
CACM 15, 3 (March 1972), pp. 135-143. . 


[Boc] Bochman, G., "Logical Verification and. Implementation of Protocols," 
Proc. Fourth Data Communications S Symposium Oct. 1975, pp. 7. 15~7. 20. 


[BBN] Bolt, Beranek, and Newnan, "Specifications for the Vatecconneetion of a 
host and an IMP," Bolt Beranek and Newnan, Inc., Cambridge, -Mass., . BBN Rep. 
1822, Dec. 1974. 7 


[Bral] Branstad, D., "Security Aspects of ‘Gupicer Networks, " ATAA eraPee ee 
Network Systems Conference, April 1973, paper 73-427,. 


{Bra2] Branstad, D., "Encryption protection in computer data commun ications," 
Proc. Fourth Data Communications Symposium, Oct. 1975, PP- 8.1-8.7. 


[Bei] Bright, S.,°"Stmulation Confirms ‘Proposed meryption Algorithm," 
Computerworld 2 9, 47 (Nov. 1975), p.. 8. : 


[Cla] Clark, D., "An Input/Output Architecture for Virtual .Memory Computer 
Syetems,"PhD Thesis, M.I.T., Dept. of Electrical Engineering, Jan. 1974. (Also 
available as M.I.T. Laboratory for Computer Science: Tech, Rep. TR-117.) iy 


[DH1] Diffie, W. and Hellman, M., "A Critique of the. proposed: Data Encryption 
Standard ," CACM 19, 3 (March 1976), pp. 164-165. 


(DH2] Diffie, W. and Hellman, M., "Multiuser — Cryptographic Techniques," to 
appear in 1976 NCC AFIPS Co f. Proc., June 1976... .., ae 


[FH1) Feistel, H., "Cryptographic coding for data. bank privacy," IBM Cotp. 
Res. Rep. RC 2827, March 1976. 


(FH2] Feistel, H., "Cryptography and computer privacy," Scientific American 
228, 5 (May 1973), pp. 15-23. 


[FNS] Feistel, H., Notz, W., Smith, J., "Cryptographic techniques for machine 


to machine data communications," IBM Corp. Res. Rep. RC 3663, December 1971; 
also in IEEE Proc. 63, 11 (Nov. 1975), pp. 1545-1554. 


Page 119 


Page 120 ; Bibliography 


[Hel] Hellman, M., "The Information Theoretic Approach to | Cryptography," 
Stanford Univ.,° Center ‘oF es eect nites LOPA ae 


[Hon] Honeywell faroruation eeercaa. ‘Inc., Honeywell Macro Assembler Progran 
Manual for Series 00/6000, ‘BN86 Rev. 2, March: suitor Be, _ 
{Hub) Huber, gee "A. Multi-Process Design oe a peta scatan." oH ‘and EE 
Tiesia, MIT Dept. of Electrical ‘Ing inesring ‘and Computer Sclence, June 1976. 
(To appear as M.I.T. Laboratory for Computer -Scince Tech. Rep.) +2 0 | 
{IBM1}- 28M; "Synchronous Bata Link GintroD-Genevak. Informations BM Corp. 
Sy@.: Bef. ‘Lib., GA27+=3093-0 “March: W774 . : 


[IBM2] IBM,"IBM 3600 Finance Communication Systea 3614 “Progranmer’ 8 “cutde, Sie 
“SBM Corp., ” 6C27-0010-0, 1974, , 


(Tso) International Standards Organization, 3057/306, Document 1005. 


$ OK 


(KD1] Kahn, _D., "The Code Battle," Playboy 225 ‘42 (Dec i: 19752, ‘ee 134. 
‘{KD2] Kahn, D., The € Codebreskere, Macafilan, = ata t967. 


{(KaR] Kahn, R., "The organization of somueer! resources into a packet vaio 
network," in “1975 noc, AFIPS Co 28 + Brec. &&, Ree Sas be nn rr ee 


(MIT] M.I.T. Laboratory for Computer = Setace "an Introduction to. Multics, i" 
‘Tech. Rep. TR 23; ia 1974. *s . 
(NBS] National ix ieau of Standards, Scacatar Data Protection, Federal Register 
40, 52 mip (1975), PP- A20GT-Eeae0s - 


[TRE] Reed, ‘D. and Kanodia, R., "Rventcounte: oh ‘New: Model ‘fer process 
Synchronization," (to appear), Jan. 1976. 


[Red] Reed, D., "Processor Multiplexing $6: aii taysred - cOpepating syatens" om 
Thesis, MIT Dept. of Electrical Engineering and Computer Science (in 
progress). (Also to appear as a M.I.T. Laboratory for Computer Science Tech. 
Rep.) 


[RW] Roberts, L., and Wessler, B., "Computer Network Development to Achieve 
Resource Sharing," in 1970 SJCC, AFIPS Conf. Proc. vol. 36, pp. 543-549. 


[Sall] Saltzer, J., "Traffic Control in a Multiplexed Computer System," ScD_ 
Thesis, MIT Dept. of Electrical Engineering, 1966. (Also available as M.I.T. 
Laboratory for Computer Science Tech. Rep. TR~30.) 


{[Sal2] Saltzer, J., "Protection and the Control of Shar ing in Multics," CACM 
17, 7 (July 1974), pp. 388-402. . 


Sb 


Bib liography . Page 121 


[SO] Saltzer, Ie and Ossanna, ees "Remote terminal character. stream processing 


in asl 1685 in: 1970 SJCC, AEIES Conf. Proc. 36, Pp- Sees 


[SS1} Saltzer, J. and dehesahaes M., ‘the. ocotctian. " of information. da 
computer aystene," Proc. IEEE 83, 9 Coeet. 1975), PP. 1287-1308. 


[sev] Savage, Jos, "Some Simple 01 f-Gynchrontzing Date. + Serwsblere,” Bell Sys. 


.[SeP] - Schmid, P.,- “Review .of Ciphering Mathods to. Achieve Commun ication 
Security in Data Transmission Networks," ‘Proc.: dnt. 2usieh Ggmiase oo on Digital 
fous. March. 1976. 


[Sch] “Schroeder, M., “Engineering a Security Kernel for Multice," Operating 
System s Beview 9, 5 (Nov. 1975), PP: ee 


{ss2] Schroeder, M. aha Saltzer, J., "A Rardvace Architecture for fapleneitine 
Protection Rings," G&CM 15, 3 (March 1972):, pp. 157~170.. 


[Sha] Shannon, C., "Communication Theory of Secrecy. Syacens, Bell Sys. ech. 


Jour. 28, 4 (Oct. 1949), PP. 656-715. 


‘[sm4] Smith, J., "The ddsten of Lucifer, a rie a cbse device for. date 
communications," IBM Corp. Res. Rep. RC 3326, "april 1971. 


[SNO] Smith, J., Notz, W., Oebeck, pe, "An Bi perimental Application of 
Cryptography to a Remotely Accessed Data aba IBM Corps Res. Rep. RC Rie, 
August 1971. a 


{Tcc] | Telenet Commun ications Corporation, Host Interface Spectttentions 
Washifigton, D.C., Mateh 1975. eee 


(ur) Tera, R.,. een Transformations for Databank ; Syste,” in 1973 “Nec, 


Bethe ye ete ae eS ate 


CS-TR Scanning Project 4 . 
Document Control Form Date : i pit 1 9s 


Report # Les-TR Ike 
Each of the following should be identified by a checkmark: 


Originating Department: 


C) Artificial intellegence Laboratory (Al) 
Laboratory for Computer Science (LCS) 


Document Type: 


Xf Technical Report (TR) CJ Technical Memo (TM) 
O Other: 


Document Information Number of pages: /2/j5 -.arcxs) 


Not to include DOD forms, printer intstructions, etc... original pages only. 


Originals are: Intended to be printed as : 
O Single-sided or 0) Single-sided or 
YX Double-sided 3X Double-sided 
Print type: 
Typewriter (] Offset Press [[] Laser Print 
([] InkJet Printer §=[[] Unknown (1) Other: 


Check each if included with document: 


pat DOD Form(L.) 1) Funding Agent Form xX Cover Page 
( Spine (1 Printers Notes C1) Photo negatives 
C] Other: 

Page Data: 


Blank PageSpy page number: 
Photographs/Tonal Material py page number: 


Other (note description/page number). 
Description : Page Number. 


BmnaGe mie! (1-/22 )Undt’&> TTL PACE, ~ 7) WNHGANK, 
y~ fay 


/23- | Scapcon tro , Co Deo (dX ‘ >) 


Scanning Agent Signoff: 
Date Received: /*/!_/75 Date Scanned: ///1/%6 — Date Returned: _/ //8 /76_ 


d 
Scanning Agent sonatwe__Dyrehat Wicep. Sista ed Piet csuiesty sonatas 


SECURITY CLASSIFICATION OF THIS PAGE (When Data Entered) 


, c READ INSTRUCTIONS 
‘PT REPORT NUMBER 2, GOVT ACCESSION NO] 5. RECIPIENT'S CATALOG NUMBER 
Technical Report 162 aie 


4. TITLE (and Subtitle) . 5. TYPE OF REPORT & PERIOD COVERED 


ENCRYPTION-BASED PROTECTION PROTOCOLS FOR S.M. Thesis 
INTERACTIVE USER-COMPUTER COMMUNICATION 


6. PERFORMING ORG. REPORT NUMBER 


Technical Report 162. 
5. OR GRANT NUMBER(e) 


NO0014-75-C-0661 


» PROGRAM ELE 
AREA & WORK 


- PERFORMING OR NIZATION NAME AN 
Massachusetts Institute o 
Laboratory for Computer Science 

545 Technology. Square 
ge sachusetts 02139 


SD « PISS S$ aC 4 
+ CONTROLLING OFFICE NAME AND ADDRESS | 12. REPORT DATE ; 
Advanced Research Projects Agency May 1976 . 


cz 
zm 
z 
a 
v 
a 
fe) 
c 
mi 
a 
a 
4 
> 
a 
r.¥ 


0 Wilson Boulevard 
eee Bey 18. SECURITY CLASS. (of thie report) 
Unclassified 


® 
m= ONTT ORIN 
Sa. OECL ASSIFICATION/ DOWNGRADING 
‘SCHEDULE 


erent from Controlling Office) 


Office of Naval Research 
Peper twent of the Navy 
Information Systems Program 


Arlington, Virginia 22217 


Approved for public release; distribution unlimited . 


+ DISTRIBUTION STATEMENT (of the abstract entered in Block 20, if different from Report) 


'8. SUPPLEMENTARY NOTES 


- KEY WORDS (Continue on reverae aide if necessary and identity by block number) 
encryption-based protection, computer security, communication security, 
block ciphers, NBS data encryption standard 


| ABSTRACT (Continue on reverse eide if neceseary and ic 


see reverse side 


DD , 5 OM, 1473 EDITION OF 1 Nov 65 IS OBSOLETE 


JAN 73 
; S/N 0102-014- 6601 | eer 
: SECURITY CLASSIFICATION OF THIS PAGE (When Data Entered) 


eran ncerine meet nines sneered 
SECURITY CLASSIFICATION OF THIS PAGE(When Data Entered) 


Block 20. 


This thesis develops a complete set of protocols, which 
utilize a block cipher,.e.g., the NBS data encryption standard, 
for protection interactive user-computer communication over 
physicall unsecured channels. The use of the block cipher 
protects against disclosure of message contents to an intruder, 
and the protocols provide for the detection of message stream 
modification and denial of message service by an intruder. The 
protocols include facilities for key distribution, two-way login 
authentication, resynchronization following channel disruption, 
and expedition of high priority messages. The thesis presents 
designs for modules to implement the protocols, both in a terminal 
and in a host computer system, and discusses the results of a test 


implementation of the modules on Multics. 


a 
SECURITY CLASSIFICATION OF THIS PAGE(When Date Entered) 


Scanning Agent Identification. Target 


Scanning of this document was supported in part by 
the Corporation for National Research Initiatives, 
using funds from the Advanced Research Projects 
Agency of the United states Government under 
Grant: MDA972-92-J1029. 


The scanning agent for this project was the 
Document Services department of the M.I.T 
Libraries. Technical support for this project was 
also provided by the M.I.T. Laboratory for 
Computer Sciences. 


darpirgt.wpw Rev. 9/94 


